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SECTION  l.  GENERAL 


1«1  Purpose  of  the  System  Specification.  This  System  Specification  for  the  Air  Force 
Integrated  Readiness  Measurement  System  (AFIRMS),  Contract  No.  F49642-83-C-0022,  is 
written  to  fulfill  the  following  objectives: 

a.  To  provide  a  detailed  definition  of  the  system  functions  and  interrelations  of 
the  wing,  major  command  (MAJCOM),  and  Headquarters  United  States  Air 
Force  (HQ  USAF)  subsystems. 

b.  To  communicate  specification  details  of  the  system  functional  requirements. 

c.  To  define,  in  detail,  the  interfaces  with  other  systems  and  subsystems  and  the 
facilities  to  be  utilized  for  accomplishing  the  interfaces. 


1.2  Introduction  To  AFIRMS.  This  section  provides  a  brief  introduction  to  the  Air  Force 
Integrated  Readiness  Measurement  System  (AFIRMS).  A  more  complete  description  is 
provided  in  the  AFIRMS  Functional  Description. 


1.2.1  AFIRMS  Synopsis. 

1.2.1. 1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to  perform 
tasked  missions  based  on  the  availability  of  specific  resources. 


a.  The  conceptual  requirements  for  AFIRMS  are  two-fold: 

(1)  Assessment  of  combat  capability  against  specific  tasking.  The  user  can 
assess  unit/force  combat  capability  against  any  planned  or  ad  hoc  tasking, 
e.g.,  War  Mobilization  Plan  (WMP),  Operation  Plan  (OPlan),  Fragmentary 
Order,  Air  Tasking  Order  (ATO),  Contingency  Plan,  etc. 

(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 

AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This  tool  permits 
comparison  of  readiness  and  sustainability  by  fiscal  year  and  can 
therefore  highlight  the  impact  of  appropriation  changes.  Thus,  changes  in 
funding  are  related  to  changes  in  force  readiness  and  sustainability.  Also, 
senior  Air  Force  decision  makers  are  supported  during  budget 
deliberations  and  Air  Force  budget  allocations. 


b. 


AFIRMS  implementation  has  two  key  concepts: 


(1)  Integrated  approach  to  tasking  based  capability  assessments.  AFIRMS  has 
two  integrative  dimensions.  First,  all  applicable  resources  and  their  usage 
interactions  are  considered.  For  example,  in  sortie  capability  assessment, 
AFIRMS  evaluates  capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies,  and  their 
generative  components  (such  as  spares  for  aircraft,  training  qualifications 
for  aircrew,  load  crews  for  munitions,  and  hot  pits  for  fuel).  Second, 
other  automated  systems  (such  as  the  Combat  Supplies  Management 
System  (CSMS),  Combat  Fuels  Management  System  (CFMS),  Weapon 
System  Management  Information  System  (WSMIS),  etc.)  outputs  are 
integrated  into  capability  assessment  calculations  through  system 
interfaces  between  those  systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than  the  data 
upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a  user  orientation 
toward  quality  assurance  of  source  data.  Unit  and  other  data  input  level 
users  are  provided  effective  tools  to  accomplish  their  daily  activities  and 
therefore  develop  a  vested  interest  in  AFIRMS  data  currency  and 
validity.  Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  validity. 


1.2. 1.2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess  readiness 
capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system,  tasking 
must  be  converted  into  a  standard  format  recognized  by  AFIRMS.  Tasking  is 
defined  in  AFIRMS  to  the  unit  level  and  may  consist  of  actual  tasking, 
hypothetical  (standard)  tasking,  or  contingency  tasking.  Any  of  these  taskings 
can  be  defined  within  specified  WMP  or  OPIan  constraints,  at  the  option  of  the 
user.  Likewise,  the  tasking  may  be  defined  by  the  user  for  present,  historic  or 
future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures  that 
information  about  inventory  status  is  available  and  accurate.  Wherever 
possible,  this  data  is  obtained  by  interface  with  other  functional  systems.  As 
with  tasking,  resource  information  can  be  defined  for  actual,  hypothetical,  or 
contingency  situations,  either  present,  historic,  or  future. 

c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to  perform  is 
the  essential  function  of  AFIRMS.  The  tasking  and  resource  data  are  processed 
to  determine  how  much  of  the  specified  tasking  can  be  accomplished  with  the 
resources  available.  Ability  to  perform  is  evaluated  in  terms  of  the  task  metric 
(sorties, etc.)  and  the  cost  metric  (dollars)  to  provide  readiness/sustainability 
and  dollars  to  readiness  assessments. 

d.  Aggregate,  Analyze  and  Present  Data.  Aggregation,  analysis  and  presentation 
ensure  the  proper  grouping  and  display  of  information  to  provide  useful 
information  at  the  unit,  major  command  and  HQ  LSAF.  Aggregation  refers  to 
the  creation  of  a  composite  understanding  of  capability  for  several  units. 
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1.2.2  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describe 
AFIRMS.  A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document. 


a.  Functional  Description  (FD).  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

c.  Management  Plan.  The  Management  Plan  provides  the  top-level 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS.  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  systems  Interface  Support  Plan. 

d.  System  Specification.  The  AFIRMS  System  Specification  adds  the 
design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems  (HQ  USAF,  HQ  USAFE  (MAJCOM),  and  Wing 
(unit))  and  assigns  functions  required  within  each  subsystem.  The 
system  specification  details  the  overall  architecture,  intersite 
interface  gateways,  processing  logic  flows  and  the  communications 
network  specifications. 

e.  Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
the  Wing  (unit/squadron).  Subsystem  specifications  detail  the 
specific  design  and/or  performance  requirements  of  the  system  at  that 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functional  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 

f.  Database  Specifications.  There  are  three  AFIRMS  database 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
Wing  (unit/squadron).  These  specifications  describe  the  database 
architecture,  size  and  content,  as  well  as  logical  data  relationships 
for  the  functions  performed  at  each  of  the  AFIRMS  levels. 

g.  Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes, 
and  groups  the  generic  types  of  data  used  in  AFIRMS.  It  also  defines 
each  type  of  AFIRMS  data  element  (attribute  class). 

h.  Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products 
which  implement  the  AFIRMS  functions  as  input  and  output  tools. 
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i.  Transform  and  Model  Descriptions.  The  Transform  and  Model 

Descriptions  Document  defines  hov  AFIEMS  calculates  the  output  data 
from  the  input  data.  Specific  algorithmic  calculations  are  provided. 
Logical  groups  of  algorithms  forming  AFIRMS  models  and  transforms  are 
described. 
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1.3  Project  References.  Accurate  assessment  of  force  readiness  and 
sustainability  has  been  a  constant  concern  of  Air  Force  commanders  and  their 
staffs.  This  concern  has  been  supported  by  an  intensified  DoD-vide  interest 
in  capability.  In  response  to  this  Air  Force  concern,  the  Directorate  of 
Operations  and  Readiness  initiated  the  AFIRMS  Program.  AFIRMS  has  been  under 
development  through  a  learning  prototype  and  is  being  designed  to  provide  Air 
Force  commanders  with  a  complete,  timely,  and  accurate  assessment  of  their 
operational  readiness  and  sustainability.  In  performing  this  function,  AFIRMS 
provides  combat  capability  assessments  to  Air  Force  leaders  at  HQ  USAF,  MAJCOM 
and  wing  levels  of  command  to  aid  them  in  making  total  force  readiness 
decisions.  AFIRMS  also  supports  day-to-day  operations  and  crisis  management 
as  well  as  planning  and  programming  activities  at  all  command  levels. 

The  Program  Management  Office  (PMO)  responsible  for  contract  management  of 
the  AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  document  is  the  Data 
Systems  Design  Office  (DSDO/XO),  Gunter  Air  Force  Station  (AFS),  Alabama;  the 
Office  of  Primary  Responsibility  (OPR)  is  the  United  States  Air  Force 
Readiness  Assessment  Group  (AF/XOOIM).  Three  operational  centers  have  been  in 
use  as  LPP  testbed  sites:  The  Pentagon,  Vashington,  D.C.;  Headquarters  United 
States  Air  Forces  Europe  (HQ  USAFE),  Ramstein  Air  Base  (AB),  Germany;  and  the 
52nd  Tactical  Fighter  Wing  (TFW),  Spangdahlem  AB,  Germany. 

References  which  are  applicable  to  the  history  and  development  of  the 
AFIRMS  Program  are  listed  below  along  with  references  concerning  programming 
and  documentation  standards. 

a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022 ,  31  May  1985.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022 ,  31  May  1985.  (Unclassified) 

c.  AFIRMS  Management  Plan,  Annex  B,  Evolutionary  Implementation  Plan, 
Final,  SofTech,  Contract  No.  F49642-83-C-0022,  31  May  1985. 
(Unclassified) 
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d.  AFIRMS  Functional  Description,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022 ,  31  May  1985.  (Unclassified) 

e.  AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No 
F49642-83-C-0022 ,  31  May  1985.  (Unclassified) 
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AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-S3-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

AFR  700-5,  Information  System  Requirements  Board,  9  November  1984. 
(Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMS),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 

AFR  700-2,  Information  Systems  Planning,  26  October  1984.  (Unclassified) 

Automated  Data  Processing  (ADP)  Security  Policy,  Procedures,  and 
Responsibilities,  AFR  205-16,  I  August  1984.  (Unclassified) 

AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (FOUO) 

Automated  Data  Systems  (ADS)  Documentation  Standards,  DoD-STD-7935. 1 , 

24  April  1984.  (Unclassified) 

Department  of  Defense  Dictionary  of  Military  and  Associated  Terms, 

3C5  Pub  1,  24  April  1984.  (Unclassified) 

AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984. 
(Unclassified) 

AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022, 

16  September  1983  (Updated  II  January  1985).  (FOUO) 


x.  AFR  300-4,  Vol.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (F0U0) 

y.  Sustainability  Assessment  Model  (formerly  CAC)  Functional 
Description,  Contract  No.  F33700-83-G-002005701,  8  April  1983. 
(Unclassified) 

z.  AFR  700-3,  Information  Systems  Requirements  Processing, 

30  November  1984.  (Unclassified) 

aa.  MIL-STD-480  Configuration  Control-Engineering  Changes,  Deviations, 
and  Waivers. 

bb.  MIL-STD-483  Configuration  Management  Practices  for  Systems, 

Equipment,  Munitions,  and  Computer  Programs. 

cc.  USAF  Operational  Major  Command  Functional  Area  Requirement  (FAR), 
SofTech,  Contract  No.  F49642-82-C-0045,  15  December  1982. 
(Unclassified) 

dd.  Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status  and  Identity 
Report  (UNITREP),  RCS:HAF-X00(AR)7112(DD) ) ,  AFR  55-15, 

22  November  1982.  (Unclassified)  t 

ee.  USAFE  Annex  to  USAF  FAR,  SofTech,  Contract  No.  F49642-82-C-0045,  20 
August  1982.  (Unclassified) 

ff.  AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396,  14  March  1980. 
(Unclassified) 
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kk.  AFIRMS  Data  Automation  Requirement  (DAR),  Final,  SofTech,  Contract 
No.  MDA-903-76-C-0396,  14  March  1980.  (Unclassified) 

11.  JCS  Memorandum  of  Policy  172,  1  June  1982.  (Unclassified) 

mm.  Military  Airlift  Command  (MAC)  AFIRMS  Requirements  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022 ,  30  September  1985.  (Unclassified) 
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1  -4  Abbreviations  and  Acronyms. 


AAC 

- 

Alaskan  Air  Command 

AB 

- 

Air  Base 

ADP 

- 

Automated  Data  Processing 

A  DPS 

- 

Automated  Data  Processing  System 

ADS 

- 

Automated  Data  Systems 

AF 

- 

Air  Force 

AFIRMS 

- 

Air  Force  Integrated  Readiness  Measurement  System 

AFLC 

- 

Air  Force  Logistics  Command 

AFLOC 

- 

Air  Force  Logistics  Operations  Center 

A FOR MS 

- 

Air  Force  Operations  Resource  Management  System 

AFRES 

- 

Air  Force  Reserve 

AFS 

- 

Air  Force  Station 

ALC 

- 

Air  Logistics  Center 

ANG 

- 

Air  National  Guard 

A  TO 

- 

Air  Tasking  Order 

A  TOC 

- 

Allied  Tactical  Operations  Center  or  Air  Tactical  Operations  Center 

BPI 

- 

Bits  Per  Inch 

BPS 

- 

Bits  Per  Second 

CAMS 

- 

Core  Automated  Maintenance  System 

CAS 

- 

Combat  Ammunition  System 

CFMS 

- 

Combat  Fuels  Management  System 

CMDS 

- 

Command  Manpower  Data  System 

COMPES 

- 

Contingency  Operation/Mobiiity  Planning  and  Execution  System 

CONPLAN 

- 

Concept  Plan 

CONUS 

- 

Continental  United  States 

CPI 

- 

Characters  Per  Inch 

CPL 

- 

Characters  Per  Line 

CPS 

- 

Characters  Per  Second 

CPU 

- 

Central  Processing  Unit 

CRC 

- 

Cyclical  Redundancy  Check:-« 

CRT 

- 

Cathode  Ray  Tube 

CSG 

- 

Combat  Support  Group 

CSMS 

- 

Combat  Supplies  Management  System 

DAR 

- 

Data  Automation  Requirement 
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DBMS 

- 

Database  Management  System 

DES 

- 

Data  Encryption  Standards 

DON 

- 

Defense  Data  Network 

DoD 

- 

Department  of  Defense 

DSDO 

- 

Data  Systems  Design  Office 

EDS 

- 

European  Distribution  System 

EIFEL 

- 

NATO  Command  and  Control  System 

EMSEC 

- 

Emanations  Security 

FAR 

- 

Functional  Area  Requirement 

FMIS 

- 

Force  Management  Information  System 

FTP 

- 

File  Transfer  Protocol 

HQ 

- 

Headquarters 

HQ  USAF 

- 

Headquarters,  United  States  Air  Force 

HQ  USAFE 

- 

Headquarters,  United  States  Air  Forces  Europe 

IAW 

- 

In  Accordance  With 

IP 

- 

Internet  Protocol 

IPS 

- 

Inches  Per  Second 

LCMS 

- 

Logistics  Capability  Measurement  System 

LPI 

- 

Lines  Per  Inch 

LPM 

- 

Lines  Per  Minute 

LPP 

- 

Learning  Prototype  Phase 

MAC 

- 

Military  Airlift  Command 

M A 3COM 

- 

Major  Command 

MDS 

- 

Mission,  Design,  Series 

MOB 

- 

Main  Operating  Base 

NBS 

- 

National  Bureau  of  Standards 

NSA 

- 

National  Security  Agency 

OPIan 

- 

Operation  Plan 

OPORD 

- 

Operation  Order 

OPR 

- 

Office  of  Primary  Responsibility 

PACAF 

- 

Pacific  Air  Forces 

PMO 

- 

Program  Management  Office 

POL 

- 

Petroleum,  Oil  and  Lubricants 

POM 

- 

Program  Objectives  Memorandum 

PPL 

- 

Preferred  Products  List 

RM 

- 

Deputy  Commander  for  Resources 

SAC 

- 

Strategic  Air  Command 

SMTP 

- 

Simple  Mail  Transfer  Protocol 

TAC 

- 

Tactical  Air  Command 

TACNET 

- 

Tactical  Air  Command  Network 

TAF 

- 

Tactical  Air  Force 

TBD 

- 

To  Be  Determined 

TCP 

- 

Transmission  Control  Protocol 

TFA 

- 

Tactical  Fighter  A  ing 

L'SAFE 

- 

United  States  Air  Forces  Europe 

A  IN 

- 

A  A  MCCS  Intercomputer  Network 

A  IS 

- 

A  A  MCCS  Information  System 

A  MP 

- 

A  ar  Mobilization  Plan 

vice 

- 

A  ing  Operations  Center 

ASM  IS 

- 

Aeapon  System  Management  Information  System 

A  A  MCCS 

- 

Aorld  Aide  Military  Command  and  Control  System 

SECTION  2.  SUMMARY  OF  REQUIREMENTS 


This  summary  provides  the  basic  characteristics  and  requirements  of  a  worldwide 
operational  AFIRMS. 

2.1  System  Description.  AFIRMS  is  a  tasking  based  capability  assessment  system  that 
assesses  readiness  and  sustainability  by  applying  specific  tasking  against  selected  unit  and 
theatre  resources  through  the  use  of  automated  readiness  models.  It  is  a  decision  support 
tool  which  provides  Air  Force  commanders  at  all  levels,  unit  through  the  Air  Staff,  with 
the  ability  to  assess  unit  readiness  and  capability  to  meet  a  tasking.  This  on-line, 
interactive  system  provides  the  capability  to  assess  readiness  to  accomplish  tasking  in 
concrete  cerms  and  use  these  assessments  to  support  "what  if"  and/or  "trade-off"  studies, 
including: 

a.  Assess  capability  against  any  tasking.  The  operator  of  the  system  can  select  a 
tasking  against  which  to  make  assessments,  i.e.,  War  Mobilization  Plan  (WMP), 
Operation  Plan  (OPlan),  what-if  Plan,  and  Air  Tasking  Order  (ATO).  AFIRMS 
then  provides  a  capability  assessment  against  that  scenario  in  a  unit  of  measure 
appropriate  for  the  tasked  mission.  For  example,  for  the  tactical  air  forces  the 
number  of  sorties  that  can  be  flown;  for  the  Military  Airlift  Command  (MAC), 
the  number  of  ton-miles  or  the  number  of  flying  hours  that  can  be  flown. 

b.  Correlate  dollars  and  readiness.  AFIRMS  provides  a  tool  for  computing 
long-term  readiness  and  sustainability  trends,  spanning  two  to  five  fiscal  years, 
which  compare  readiness  and  sustainability  by  fiscal  year  and  relate  the 
impacts  of  appropriations  by  fiscal  year. 

The  worldwide  operational  AFIRMS  is  a  hierarchically  distributed  system  which  can 
be  visualized  as  a  pyramid  of  distinct  operational  sites.  (5ee  Figure  2-1)  Each  operational 
site  performs  a  set  of  functions  which  are  distinct,  although  similar,  from  other  sites. 

This  information  is  transmitted  upward  to  a  parent  site.  There  are  three  basic  levels 
within  the  AFIRMS  pyramid,  each  level  being  considered  as  an  AFIRMS  subsystem.  The 
highest  level  subsystem,  the  apex  of  the  pyramid,  is  the  HQ  USAF  subsystem.  The  second 
level  of  the  pyramid  consists  of  the  M  AJCOM  subsystems.  The  base  of  the  pyramid  is 
composed  of  a  set  of  wing  subsystems. 
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Figure  2-1.  AFIRMS  Structure 


The  AFIRMS  capability  provides  the  Air  Force  with  a  system  which: 

a.  Assesses  readiness  of  a  unit  or  force  to  perform  a  specific  tasking. 

b.  Projects  the  sustainability  of  a  force  or  unit  against  a  specific  tasking. 

c.  Relates  cost  to  a  specific  current,  future,  or  historic  tasking. 

d.  Projects  readiness  to  perform  a  specific  tasking  forward  in  time. 

e.  Traces  readiness  to  perform  a  specific  tasking  historically. 

f.  Provides  responses  to  hypothetical  situations  (what-if). 

g.  Provides  responses  to  ad  hoc  queries. 


2.1.2  AFIRMS  Subsystems.  AFIRMS  will  consist  of  three  subsystems  that  interrelate  and 
communicate  to  provide  the  AFIRMS  capability.  The  subsystems,  named  in  accordance 
with  the  command  levels  they  are  to  serve,  are  the  HQ  USAF,  MAJCOM  and  wing 
subsystems. 
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Each  subsystem  provides  certain  functionality  to  the  users  in  order  to  support  the 
primary  AF1R.US  functions.  The  following  functions  are  provided,  to  some  degree,  to 
users  at  each  subsystem  level: 

a.  Provide  for  entering/retrieving  data  into/from  an  AF1RMS  database. 

b.  Display  information  concerning  readiness  and/or  budget  analysis  via  graphic 
displays  in  both  color  and  black-and-white. 

c.  Provide  hardcopy  outputs  of  displayed  data  on  request. 

d.  Provide  capability  to  conduct  what-if  or  trade-off  exercises  related  to 
readiness  and/or  budgetary  questions. 

e.  Provide  capability  to  execute  adhoc  queries  against  the  database  at  the  local 
site  within  the  constraints  of  access  control  and  security  requirements. 

2. 1.2. 1  HQ  USAF  Subsystem.  The  HQ  USAF  subsystem  supports  Air  Staff  day-to-day,  as 
well  as  exercise  and  crisis  decision  making.  The  HQ  USAF  subsystem  assists  Air  Staff 
management  in: 

a.  Analyzing  resource  needs  and  expenditures. 

b.  Preparing,  defending,  and  administering  the  U.S.  Air  Force  budget. 

c.  Obtaining,  controlling,  and  allocating  the  resources  of  manpower,  money,  and 
material  needed  for  support  of  the  combat  forces. 

d.  Supporting  crisis  and  exercise  decision  making. 

e.  Relating  changes  in  funding  to  changes  in  force  readiness  and  sustainability. 

f.  Assessing  combat  capability  reflective  of  aggregate  theatre  resources  and 
shortfalls  (from  a  worldwide  perspective). 

g.  Depicting  trends  in  resource  needs  forward  and  backwards  in  time. 


2. 1.2.2  MA3COM  Subsystem.  The  MA3COW  subsystem  provides  readiness  assessment 
information  that  assists  M  A  3COM  personnel/management  in: 


a.  Assessing  planning  and  tasking  resource  requirements. 

b.  Evaluating  the  appropriateness  of  tasking. 


Distributing/allocating  resources. 
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d.  Supporting  POM  deliberations. 


e.  Supporting  crisis  and  exercise  decision  making. 

f.  Assessing  combat  capability  reflective  of  aggregated  unit  resources  and 
shortfalls  (from  a  theatre-wide  perspective). 

g.  Assessing  alternative  proposals  for  allocation  of  resources  or  assignment  of 
tasking(s). 

2. 1.2.3  Wing  Subsystem.  The  AFIRMS  wing  subsystem  provides  readiness  assessment 
information  that  assists  wing  level  management  in: 

a.  Evaluating  their  ability  to  accomplish  tasking  directed  by  higher  levels  of 
command. 

b.  Evaluat  ng  tasking  execution  alternatives. 

c.  Identifying  and  reporting  shortfalls  related  to  tasking. 

d.  Reporting  readiness  up  the  chain  of  command. 

e.  Projecting  readiness  capability. 

AFIRMS  v  ing  products  present  a  look  at  wing  resources  from  operations, 
maintenance,  and  support  squadron  functional  wing  areas,  and  provide  an  integrated 
assessment  of  readiness  and  sustainability  using  these  wing  resources. 

2.2  System  Functions.  The  AFIRMS  functions  are  distributed  among  the  three 
subsystems.  Some  functions  are  unique  to  a  subsysten,  and  some  functions  are  repeated 
across  subsystems.  Functions  repeated  across  subsystems  provide  more  global,  unified 
views  of  readiness  capability.  Three  levels  of  functions  are  of  interest  in  this  system 
specification.  They  are:  Basic  AFIRMS  Functions,  Support  Functions,  and  System 
Functions. 

a.  Basic  AFIRMS  Functions.  The  building  block  functions  which  are  specific  to 
AFIRMS  and  which  are  used  (in  different  forms  and  combinations)  to  support 
the  user  with  various  types  of  data/information.  The  Basic  AFIRMS  Functions 
include: 

(1)  Translate  Tasking.  Translates  tasking  so  that  it  can  be  used  in  measuring 
ability  to  perform,  i.e.,  converts  tasking  to  quantities  of  aircraft,  crews, 
munitions,  Petroleum,  Oil,  and  Lubricants  (POL),  etc.  required  to 
accomplish  that  tasking.  The  Translate  Tasking  function  assists  in  task 
assignment. 
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(2).  Define  Resources.  Provides  inventory  status  and  availability  of  resources 
(such  as  fuels,  munitions,  aircraft  and  crews)  for  use  in  capability 
assessments.  The  Define  Resources  function  assists  in  allocation  of 
resources  (physical  and  fiscal)  and  forecast  results  of  trial  or  final 
allocations. 


(3)  Determine  Ability  to  Perform.  Given  current  and  forecast  readiness 
factors,  AFIRMS  transforms  WMPs,  ATOs,  OPlans,  and  what-if  exercises 
into  measurable  tasking;  computes  current  readiness  to  perform  the  task, 
projects  readiness  into  the  future,  calculates  resources  consumed  by 
performing  the  task,  and  prepares  schedules  for  performing  the  task.  This 
function  provides  users  with  the  capability  to  measure  (and  aggregate) 
readiness  and  sustainability  vs.  standard  or  one-time  tasking,  and  measure 
(and  aggregate)  readiness  or  sustainability  vs.  revised  standards,  and/or 
revised  standard  tasking  using  historic  data. 

(4)  Aggregate,  Analyze  and  Present  Data.  This  function  deals  with  the  task  of 
properly  grouping  data  from  various  wings  to  provide  meaningful  and 
useful  data  at  MAJCOM  and  HQ  USAF  levels.  It  also  develops  trend  and 
variance  data  to  facilitate  exception  reporting  on  unusual  developments  in 
day-to-day  data.  Aggregation  refers  to  the  creation  of  a  composite 
understanding  of  the  readiness  and  sustainability  of  a  number  of  units. 
Thus,  a  MAJCOM  with  many  reporting  wings,  each  with  its  own 
deficiencies  and  strengths,  can  assess  the  readiness  (and  sustainability)  of 
all  units  taken  as  a  whole. 

b.  Support  Functions.  In  order  to  carry  out  the  basic  AFIRMS  functions,  AFIRMS 
maintains  and  verifies  data  via  a  variety  of  associated  support  capabilities 
which  are  not  directly  related  to  readiness  assessment,  such  as: 

(1)  Display  resource  inventories  and  status. 

(2)  Report  reduction  of  resources  below  thresholds  or  exceeding  upper  limits. 

(3)  Display  tasking. 

(4)  Display  information  on  an  evolving  schedule. 

(5)  Perform  local  ad  hoc  queries. 

(6)  Perform  ad  hoc  calculations. 

c.  System  Functions.  The  standard  building  block  functions  such  as  graphics  or 
data  management  which  might  occur  in  any  system,  and  which,  together  with 
specially  written  subfunctions,  are  used  to  support  the  Basic  AFIRMS 
functions.  The  generic  System  Functions  employed  by  AFIRMS  include: 

(1)  Produce  graphic  and  tabular  displays. 

(2)  Store  and  retrieve  data. 

(3)  Collect  trends  and  averages  for  use  in  computations. 
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(4)  Edit  input  data  -  check  reasonableness. 

(5)  Provide  user  interface  to  AFIRMS  services. 

(6)  Maintain  security. 

(7)  Provide  intersite  and  local  communications. 

(S)  Interface  to  other  systems. 

(9)  Provide  for  transmission  of  data,  on  a  periodic  basis  and  an  exception 
basis,  from  the  lower  level  sites  to  the  higher  level  sites. 

(10)  Provide  for  storage  and  retrieval  of  current  data  at  all  sites. 

(1  1)  Provide  for  storage  and  retrieval  of  historical  data  at  all  sites. 

(12)  Provide  for  security  of  classified  data  both  from  a  system  access 
standpoint  and  from  a  data  communications  standpoint. 


2.2.1  Accuracy  and  Validity.  The  accuracy  of  the  AFIRMS  database  is  essential  for  the 
generation  of  accurate  measurements.  There  are  two  categories  of  accuracy  and  validity 
that  must  be  addressed.  The  first  is  related  to  electronic  manipulation,  storage,  and 
transmission  of  data  in  the  AFIRMS  system.  The  second  is  related  to  the  interface 
between  the  user  and  the  AFIRMS  system. 


a.  Electronic  Manipulation/Storage/Transmission. 

( 1)  The  nature  of  the  models/displays  created  with  AFIRMS  does  not  require 
precision  beyond  that  achievable  with  of  1-the-shell  standard  micro  or 
minicomputers  that  support  hardware  or  software  floating  point 
computations. 

(2)  Errors  in  data  transmissions  will  not  exceed  1  in  10^.  (Parity  checking 
and  C;  ' ical  Redundancy  Checking  (CKC)  ensure  that  the  data  actually 
used  internal  to  the  AFIRMS  sites  has  an  error  probability  well  below  this 
figure  by  correcting  all  I -bit  errors.  Double-bit  errors  are  detected  but 
not  corrected.) 

b.  I  ser  Interfaces  to  AFIRMS.  The  user  interfaces  of  interest  here  are  those 
interfaces  that  introduce  new  information  into  AFIRMS.  The  concern  is  that 
the  information  destined  to  enter  the  database  be  valid.  Valid  here  means  that 

( 1)  The  individual  entering  the  information  is  authorized  to  do  so  (i.e.,  only 
fuels  personnel  may  be  authorized  to  update  fuels  information). 

(2)  The  information  is  as  "error  free  as  possible."  This  suggests  that  input 
data  must,  in  general,  be  entered  through  well-engineered  interlaces  that 
prompt  the  user  and  check  field  contents. 
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(3)  Certain  information  passed  into  the  database  has  sufficient  criticality  to 
require  that  verification  beyond  that  identified  in  (2)  above,  occur  prior  to 
database  updates.  This  verification  occurs  via  supervisory  review. 

Under  this  method,  the  data  is  entered  by  an  authorized  individual. 
However,  the  information  cannot  be  updated  in  the  database  or  be 
transmitted  to  higher  headquarters  by  the  individual  who  entered  it  until  a 
supervisor  authorizes  the  AFIRMS  system  to  accept  the  data.  The  method 
of  authorization  might  require  that  the  supervisor  logon  to  the  AFIRMS 
system  and  enter  an  "unlocking"  command  that  allows  the  data  to  be 
entered,  the  database  updated,  or  the  data  transmitted. 

c.  System  Interfaces  to  AFIRMS.  Data  obtained  by  interface  with  other  data 
systems  is  subject  to  the  same  data  accuracy  and  validity  criteria  as  for  user 
interface  data. 


2.2. 1.1  Data  Accuracy.  AFIRMS  uses  five  main  approaches  to  ensure  the  accuracy  and 
currency  of  data.  These  are  to: 


a.  Provide  benefits  to  the  organizations  which  input  readiness  data.  If  the 
organization  which  inputs  data  receives  benefits  from  the  system  in  its  day  to 
day  operations,  then  motivation  is  provided  to  ensure  that  data  entered  is 
current  and  accurate. 

b.  Simplify  data  input  by  using  simple  devices  and  by  grouping  inputs.  For 
example,  a  lookup  reference  table  is  a  device  for  entering  identification  number 
(such  as  an  aircraft  tail  number)  that  might  be  subject  to  error  if  entered  via 
keyboard. 

c.  Use  automated  edit  checks  as  well  as  checks  for  the  reasonableness  of  input 
data  against  stored  parametric  values.  That  is,  all  inputs  are  programmatically 
edited  to  further  ensure  the  accuracy  and  integrity  of  the  database.  The 
system  validates  length,  format  and  legal  values  of  all  formatted  alphanumeric 
input  data. 

d.  All  data  entry  information  is  checked  for  consistency  against  other  related 
information. 

e.  Obtain,  edit,  and  incorporate  data  and/or  assessments  from  other  automated 
systems. 


User  Response  Time.  AFIRMS  is  an  information  processing  system  which  is 
user  intensive;  that  is,  in  general,  users  enter  data  through  a  data  capture 
device  and  request  readiness  status  to  an  output  display.  Thus,  AFIRMS 
interactive  CRT  terminal  response  times  to  user  requests  are  minimized. 
Response  time  as  it  applies  to  user  terminals,  consists  of  two  parts:  command 
acceptance  and  command  execution. 

(1)  Command  Acceptance.  Command  acceptance  is  the  time  between  the 
user's  initiating  transmission  of  a  command  or  transaction  to  the  system 
(such  as  by  depression  of  the  ENTER  key  or  entry  of  the  last  character  of 
a  menu  response)  and  the  appearance  of  the  first  line  of  the 
acknowledgement  from  the  system  on  the  user's  terminal  that  the 
message  has  been  received,  an  error  condition  exists,  or  processing  has 
been  completed.  AFIRMS,  under  loaded  conditions  (not  less  than  25%  of 
terminals  in  use)  supports  a  command  acceptance  time  of  less  than  2.5 
seconds  90%  of  the  time.  At  no  time  will  command  acceptance  time 
exceed  six  seconds. 

(2)  Command  Execution.  Command  execution  is  the  elapsed  time  between  the 
command  or  transaction  entry,  and  the  appearance  of  the  first  line  of 
executed  results  of  that  entry  on  the  user's  display  terminal  (excluding 
graphics). 

(a)  For  functions  such  as  command  entry,  text  editing  or  message 
writing  applications,  the  appearance  of  a  keyed  character  on  the 
screen  will  be  immediate  in  the  perception  of  the  user. 

(b)  Queries 

a  Simple.  Response  time  1-3  seconds. 

b  Moderately  Complex.  Response  time  4-10  seconds. 

c  Complex.  Response  time  1  1  seconds  or  greater. 

Database  Updates.  The  user  performs  screen  updates  to  the  AFIRMS 
database(s)  in  one  of  two  ways.  The  user  has  the  option  of  updating  the 
database  automatically  upon  exiting  an  input  screen,  or  the  user  can  request  an 
update  at  any  point  in  time  after  data  has  been  entered  and/or  changed. 

AFIRMS  database  update  frequency  is  as  specified  in  the  subsystem 
specifications  for  the  individual  functional  areas. 


2.3  Flexibility.  AFIRMS  provides  a  skeleton  structure  (system  architecture) 
that  matches  the  specific  requirements  of  each  installation  to  an  AFIRMS  site 
with  compatible  hardware/sof tvare  capability.  Additionally,  this  system 
architecture  has  the  capability  to  grow,  i.e.,  add/change  system  capabilities 
as  time  passes.  Capabilities  which  are  incorporated  for  adapting  the 
subsystems  to  changing  requirements  include  the  following: 


a.  AFIRMS  sites  are  constructed/configured  from  modular  hardware  and 
software  components.  The  modular  applications  software  is  written  in 
host  independent  high  order  languages  for  ease  of  transportabi  lity 
between  different  hardware  configurations. 

b.  This  hardware/software  building  block  approach,  coupled  with 
transportable  software,  assures  that  operational  AFIRMS  expansion  in 
the  future  can  follow  a  systematic  pattern  with  an  optimum  amount  of 
standardization  among  sites. 

c.  Utilization  of  OoO  standardized  data  communications  protocols  and 
external  user  interfaces.  AFIRMS  implements  DoD  standard  protocols 
for  network  and  distributed  system  data  communications  and  terminal 
interfaces.  (Ref.  Section  3. 2. 1.3)  Utilization  of  the  DoD  standard 
protocols  provides  for  interoperability  among  different  vendor 
equipments,  existing  and  developmental  Air  Force  ADP  systems,  and  is 
in  accordance  with  Air  Force  policy  and  guidance. 

d.  Ability  to  interface  an  AFIRMS  site  to  other  Air  Force  or 
MAJCOM-unique  ADP  systems  after  the  AFIRMS  site  has  been  designed  and 
installed.  The  central  idea  is  that  the  AFIRMS  software  be 
structured  so  as  to  provide  for  new  system  integration  to  the 
greatest  extent  possible.  This  is  facilitated  by  maintaining 
distinct  layers  of  software,  as  in  the  International  Standards 
Organization  (ISO)  7-layer  Reference  Model. 

e.  Ability  to  support  different  communication  protocols  within  the 
AFIRMS  superstructure.  Primary  interfaces  are  defined  as  those 
communication  transactions  between  neighboring  AFIRMS  entities  (e.g. 
HQ  USAF  —  MAJCOM,  MAJCOM  —  VING  [See  Figure  2-1])  and  between 
subsystem  central  nodes  and  their  associated  functional  areas  [See 
Figure  4-2].  By  standardizing  a  set  of  strict  interface  formats  for 
each  primary  interface,  AFIRMS  provides  the  flexibility  to  utilize 
different  protocols;  changing  the  envelope  has  no  effect  on  its 
contents.  This  allows  the  optimal  and  cost-effective  utilization  of 
available  hardware  and  software. 
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f. 


Ability  to  support  secondary  (or  backup)  interfaces,  by  which  an 
intermediate  AFIRMS  site  may  be  bypassed  when  the  need  arises.  For 
example: 


The  ability  of  a  functional  area,  in  place  or  deployed,  to 
communicate  directly  with  a  MAJCOM 


or 

•  The  ability  of  a  WING,  in  place  or  deployed,  to  bypass  the 
MAJCOM  and  communicate  directly  with  HQ  USAF. 
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SECTION  3.  ENVIRONMENT 


3.1  Equipment  Environment.  Equipment  is  provided  to  each  AF1RMS  site  on  an  "as 
needed"  basis.  It  is  the  intent  of  AFIRMS  to  use  existing  facilities  and  equipments 
wherever  possible.  However,  at  a  minimum,  each  AFIRMS  site  contains  the  equipment 
required  for  the  Central  Node  and  one  Functional  Area  workstation.  The  Central  Node 
contains  the  AFIRMS  database  for  that  site  as  well  as  the  communications  support  for  site 
to  site  communications. 

AFIRMS  utilizes  standard  Air  Force  equipment  sources  such  as  the  Air  Force 
Standard  Multiuser  Small  Computer  Initiative  by  the  Air  Force  Computer  Acquisition 
Center,  TEMPEST,  and  Phase  IV  Program  equipment  sources.  AFIRMS  is  designed  to 
allow  for  the  integration  of  different  computers,  peripherals,  and  communication 
standards  (Ref.  2.3,  3.1.4,  3.2. 1.3)  throughout  the  system.  This  provides  for  a  faster  and 
more  cost-etficient  AFIRMS  development,  and  a  higher  degree  of  operational  flexibility. 


3.1.1  Central  Node  Equipment.  Each  AFIRMS  site  will  contain  a  Central  Node 
consisting  of  the  following  equipment: 


a.  One  or  more  processors,  each  capable  of  handling  four  or  more  functional 
areas.  Each  processor  is  a  32-bit  machine  with  at  least  a  24-bit  address 
structure.  Each  processor  has  several  high  bandwidth  full  duplex 
communications  paths  to  the  other  processors,  if  any,  in  the  central  node.  Each 
processor  has  the  ability  to  connect  three  or  more  terminals. 

b.  One  or  more  direct  access,  high  speed  storage  devices  capable  of  containing  the 
centralized  data  base  and  capable  of  being  accessed  by  multiple  processors. 
Each  high  speed  storage  device  has  at  least  one  high  bandwidth  full  duplex 
communications  path  to  each  of  the  processors  in  the  central  node. 

c.  One  direct  access,  high  speed  storage  device  capable  of  containing  all  software 
and  system  files  for  each  processor  in  the  Central  Node. 

d.  A  mass  storage  device,  i.e.  9-track  tape  or  optical  storage  device,  capable  of 
being  accessed  by  multiple  processors. 

e.  A  communications  controller  capable  of  handling  all  external  communications 
lines  and  capable  of  being  accessed  by  multiple  local  processors. 
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f.  Encryption  devices  for  each  physical  line  that  may  pass  classified  data.  The 
encryption  device  is  able  to  operate  in  a  synchronous  or  asynchronous  mode  and 
to  operate  at  the  speeds  required  by  the  communications  lines. 

g.  Power  conditioning  and  failure  protection  mechanisms  are  required.  All  "wall 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Power 
failsafe  backup  provisions  are  provided  to  preserve  memory  in  the  event  of 
power  failure.  Backup  power  terminates  during  normal  shutdown. 

h.  A  CRT  terminal  and  line  printer  for  development  and  maintenance  purposes. 

i.  Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  four 
megabytes  of  user  memory  is  required.  This  user  memory  is  expandable  (in 
minimum  512K  byte  increments)  up  to  at  least  10  megabytes.  All  memory 
specifications  are  made  in  S  bit  bytes.  The  physical  organization  of  the  main 
memory  is  modular  so  that  a  failure  in  one  module  (except  the  module 
containing  the  operating  system)  does  not  deprive  the  system  of  the  remaining 
memory. 

(1)  Error  Detection.  As  a  minimum,  memory  error  detection  and  correction 
features  are  provided  that  detect  double  bit  errors  and  correct  all  single 
bit  errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  memory  areas  not 
allocated  to  that  program  is  provided. 


3.1.2  Functional  Area  Equipment.  Each  functional  area  which  needs  to  access,  enter,  or 
modify  AF1RMS  data  is  provided  with  a  functional  area  workstation  to  communicate  with 
the  Central  Node.  Each  functional  area  workstation  contains  the  following  equipment: 


a.  One  processor  capable  of  handling  one  or  more  users  depending  on  the  needs  of 
the  functional  area.  The  processor  is  at  least  a  16-bit  machine. 

b.  One  direct  access,  high  speed  storage  device  capable  of  containing  the  local 
data  base  and  the  software/system  files. 

c.  A  mass  storage  device,  i.e.  disk  drive. 

d.  A  communications  controller  capable  of  handling  all  external 
asynchronous/synchronous  communications  between  the  functional  area 
workstation  and  the  central  node. 
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e.  Several  miscellaneous  input/output  devices.  The  number  of  each  type  of  device 
depends  on  the  requirements  of  the  functional  area,  and  will  be  determined 
during  the  analysis  phase  that  precedes  implementation  at  each  site. 

f.  An  encryption  device  for  communicating  with  the  Central  Node  if  the 
workstation  is  to  handle  classified  data.  The  encryption  device  is  able  to 
operate  either  in  a  synchronous  or  asynchronous  mode,  and  to  operate  at  the 
speeds  required  by  the  communications  lines. 

g.  Power  conditioning  and  failure  protection  mechanisms  are  required.  All  "wall 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Power 
failsafe  backup  provisions  are  provided  to  preserve  memory  in  the  event  of 
power  failure.  Backup  power  must  terminate  during  normal  shutdown. 

h.  Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  two 
megabytes  of  user  memory  is  provided.  This  user  memory  is  expandable  (in 
minimum  512K  byte  increments)  up  to  at  least  8  megabytes.  All  memory 
specifications  are  made  in  8  bit  bytes.  The  physical  organization  of  the  main 
memory  is  modular  so  that  a  failure  in  one  module  (except  the  module 
containing  the  operating  system  nucleus)  shall  not  deprive  the  system  of  the 
remaining  memory. 

(1)  Error  Detection.  As  a  minimum,  a  memory  error  detection  and  correction 
feature  is  provided  that  detects  double  bit  errors  and  corrects  all  single 
bit  errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  memory  areas  not 
allocated  to  that  program  is  provided. 


3.1.3  Input/Qutput  Devices.  The  device  requirements  of  each  AFIRM5  site  for  CRT 
terminals,  printers,  disk  drives,  and  magnetic  tape  drives  is  determined  during  the  analysis 
phase  that  precedes  implementation  at  that  site. 

a.  CRTs  must  possess  the  following  characteristics: 

(1)  Monochrome  Terminals:  Alphanumeric  keyboard  and  video  display; 
interface  via  standard  R5-232-C  port;  be  able  to  function  as  a  system 
console;  and  when  the  ASCII  "BEL"  character  or  its  equivalent  is  received, 
an  audible  tone  or  "BEEP"  must  be  sounded. 

(a)  Keyboard: 

J_  Must  be  capable  of  generating  the  ASCII  128-character  subset 
in  accordance  with  (IAW)  FIPS  PUB  1. 

2  At  a  minimum,  must  conform  to  the  ANSI  standard  X4.14-1971. 


3  Must  have  a  repeat  function  for  ail  printable  ASCII  characters, 
cursor  controls,  and  spacing  functions. 

4  Must  have  separate  keys  for  carriage  return,  control,  escape, 
and  spacing  functions. 

5  Must  have  a  minimum  of  16  programmable  function  keys 
usable  as  AFIRMS  bezel  keys. 

6  Must  have  a  numeric  keypad  to  the  right  of  the  character  keys 
and  allow  numeric  entries  from  either  the  regular  character 
key  or  the  numeric  keypad. 

7  Have  at  least  four  cursor  movement  keys  separate  from 
function  keys. 

S  Have  a  detachable  keyboard. 

9  Have  a  (screen)  hardcopy  function. 

(b)  Video  Display  must  possess  the  following  characteristics: 

1  Must  display  a  minimum  of  24  lines  of  132  characters  each. 

2  Characters  displayed  must  consist  of  the  ASCII  95-character 
subset  IAW  FIPS  PUB  15,  Section  1. 

3  If  the  dot  matrix  character  generation  technique  is  used,  the 
matrix  must  be  at  least  7x9. 

4  Full  descenders  will  be  used  on  the  lower  case  such  as  "g,  j,  p, 
q,  y"  and  appropriate  special  characters. 

5  Must  implement  a  visible  cursor  denoting  the  next  character 
position  in  such  a  manner  that  its  location  is  obvious  to  the 
operator  and  does  not  obscure  any  information  (excluding 
underline)  which  may  be  displayed  at  that  position. 

6  The  cursor  must  be  addressable  and  the  capability  must  be 
provided  for  the  applications  program  to  clear  the  display  and 
to  position  the  cursor  at  any  location  on  the  screen. 

7  Must  have  a  non-glare  viewing  surface. 

8  Must  provide  reverse  video,  bold,  blink,  and  underscore  video 
capabilities  under  application  program  control. 

9  Brightness  must  be  externally  adjustable  by  the  terminal 
operator. 


10  The  display  must  be  green  or  amber. 

1  1  Must  have  selectable  terminal  transmission  rates  of  12GG, 
2400,  4800,  9600  and  19,200  bps. 

1  2  Must  have  a  minimum  1  f-inch  screen  measured  diagonally. 

1  3  Must  have  smooth  scrolling  capability. 

14  Must  support  shading  and  marking  patterns  (preprogrammed 

and  programmable). 

(c)  Other  Required  CRT  Terminal  Characteristics: 

J_  Local  memory. 

2  Built-in  diagnostics  and  testing. 

3  TEMPEST  certification  -  for  terminals  which  display  classified 
information. 

4  Screen  print  function. 

(2)  Color  Graphics  Terminals  must  possess  the  following  characteristics: 

(a)  Minimum  of  1 6  special  function  (programmable)  keys.  Please  refer 
to  Table  3-1  for  some  of  the  required  key  features. 

(b)  10%  of  the  terminals  will  have  a  video  interface  board  for  use  with 
video  projectors. 

(c)  Screen  definition  of  not  less  than  720x484  individually  addressable 
and  color  definable  pixels  (i.e.,  medium  resolution). 

(d)  Minimum  1 1"  CRT  screen. 

(e)  TEMPEST  certified  -  for  terminals  which  display  classified 
information. 

(f)  Support  9600  baud  rate. 

(g)  Display  a  minimum  of  16  colors. 

b.  Printers  must  possess  the  following  characteristics: 

(I)  Letter  Quality  Printers: 

(a)  Print  at  least  55  characters  per  second. 

(b)  Print  at  least  1  32  characters  per  line. 
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(c)  Have  a  pressure-feed  mechanism,  interchangeable  tractor  feed  and 
an  automatic  single  sheet  feeder. 

(d)  Print  the  complete  95  character  ASCII  subset  IA\t  FIPS  PLB  15, 

Section  1.  • 

(e)  Have  operator  selectable  print  spacing  of  10  pitch,  12  pitch,  anG 
proportional  spacing. 

(f)  Accept  forms  from  4  1/2  to  at  least  14  7/8  inches  in  width. 

(g)  Print  clearly  up  to  3  part  paper. 

(h)  Interface  via  RS-232-C  serial  port  or  parallel  port. 

(i)  Provide  at  least  one  font  which  is  OCR  readable. 

(j)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  that 
indicates  the  standard  first  print  position. 

(k)  Have  operator  controls  for  power  online/offline,  advance  to  top  of 
form  and  manual  adjustment  of  vertical  and  horizontal  paper 
alignment. 

(l)  Be  TEMPEST  certified,  when  used  for  classified  information 
printout. 

(2)  Dot  Matrix  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  200  CPS  at  132  characters  per  line  at  10  characters 
per  inch. 

(b)  Have  dot  addressable  graphics  with  a  minimum  resolution  of  70  dots 
per  inch  vertical  and  horizontal. 

(c)  Provide  correspondence  duality  print  capability  of  at  least  40  CPS 
at  10  CPI. 

(d)  Use  an  operator  adjustable  pin  feed  tractor  for  positive  form 
registration  movement. 

(e)  Print  the  complete  95  character  ASCII  subset  IAW  FIPS  PLB  15, 
Section  I. 

(f)  Accept  forms  ranging  from  4  1/2  to  14  7/8  inches  in  width. 

(g)  Print  full  descenders  used  on  the  lower  case  characters  "g,  |,  p,  q,  >" 
and  appropriate  special  characters. 

(h)  Print  6  and  8  lines  per  inch,  operator  selectable. 

(i)  Print  clearly  up  to  3  part  paper. 


(j)  Have  controls  for  power,  online/offline,  advance  to  top  of  form  and  . 
manual  adjustment  of  vertical  and  horizontal  paper  alignment. 

(k)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  that 
indicates  the  standard  first  print  position. 

(l)  Under  program  control,  line  feed,  and  form  feed. 

(m)  Interface  via  RS-232-C  serial  port  or  parallel  port. 

(n)  Be  TEMPEST  certified. 

(3)  High  Speed  (Line)  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  500  LPM  (at  132  CPL)  using  the  character  set  in  (b). 

(b)  Print  the  complete  95  character  ASCII  subset  IAW  FIPS  PUB  15, 
Section  1. 

(c)  Support  horizontal  spacing  of  10  or  12  CPI. 

(d)  Have  vertical  spacing  of  6  or  8  LPI  switch  or  programmer  selectable. 

(e)  Print  at  least  132  characters  per  line. 

(f)  Print  clearly  up  to  3  part  paper. 

(g)  Have  vertical  format  control  via  programmer  or  printer. 

(h)  Be  TEMPEST  certified. 

(i)  Have  a  diagnostic  LED  indicator  for  status. 

(j)  Interface  via  standard  RS-232-C  ports  and  parallel  port. 

(4)  Color  Graphics  Printers  must  possess  the  following  characteristics: 

(a)  Plot  the  displayed  graph  in  no  more  than  90  seconds. 

(b)  Provide  minimum  resolution  of  100x85  horizontal  to  vertical  dots 
per  inch. 

(c)  Print  at  least  eight  colors. 

(d)  Print  on  Bond  paper  and  transparency  (developing  not  acceptable). 

(e)  Interface  via  standard  R5-232-C  ports  and  a  parallel  port. 


(f)  Accept  a  minimum  paper  size  ot  S.5xl  1  inches. 

(g)  Be  TEMPEST  certified. 


c.  Floppy/Microfloppy  Disk  Drives  must  possess  the  following  characteristics: 

(1)  Minimum  of  two  read/w  rite  heads  to  provide  access  to  double-sided  disks. 

(2)  Provide  a  formatted  storage  capacity  for  one  diskette  of  at  least  1.5 
megabytes. 

(3)  Use  a  minimum  of  a  5.25  inch  double  sided/double  density  diskette  for 
floppy  disk  drives  and  3.5  inch  diskette  for  microfloppy  disk  drives. 

(4)  Be  compatible  with  functional  area  workstation  hardware  selection. 

d.  Magnetic  Tape  Drives  must  possess  the  following  characteristics: 

( 1)  Are  nine  (9) track. 

(2)  Support  a  10.5  inch  reel  of  .5  inch  by  2400  foot  standard  reel  tape. 

(3)  Support  speed  read/write  operations  at  a  minimum  of  75  IPS,  streaming  at 
a  minimum  of  2CC  IPS. 

(4)  Perform  error  checking  on  all  read  operations. 

(5)  On  all  write  operations,  be  capable  of  performing  a  read  after  write  with 
error  checking. 

(6)  Have  write  protection  and  beginning  and  end  of  tape  sensor. 

(7)  Have  a  minimum  of  dual-density  (1600/6250  BP1  capability). 


3.1.4  Communications  Equipment.  Communications  equipment  is  provided  to  supply  both 
a  primary  and  a  secondary  secure  communications  path  to  all  higher  and  lower  level  sites. 
P eauirerr  ents  for  specific  types  and  quantities  of  communications  hardware  w  ill  be 
determined  during  the  analysis  phase  that  precedes  implementation  at  each  site. 


3. 1.4.1  Primary  Intersite  Communications.  Primary  communications  equipment  between 
subsystems  must  provide  the  following  capabilities: 

a.  Encryption  of  both  classified  and  unclassified  data  transmitted  to  anc  Irom 
subsystems. 

b.  A  Transmission  rate  of  96CC  baud  or  greater  using  either  asynchronous  or 
synchronous  equipment. 

c.  A  24-hour-a-day  dedicated  line  between  subsystems. 

d.  Conditioning  to  a  bit  error  rate  of  1  in  10^. 


3. 1.4.2  Secondary  Intersite  Communications.  Secondary  (Backup)  communications 
equipment  must  provide  the  following  capabilities: 


a.  Encryption  of  data  transmitted  between  sites. 

b.  A  transmission  rate  of  30G  baud  or  greater  using  either  asynchronous  or 
synchronous  equipment. 

c.  Multiple  physical  paths  for  a  single  logical  path  (e.g.,  rerouting). 

d.  Availability,  as  required,  in  the  event  primary  communications  fail.  Over  a 
given  24-hour  period,  secondary  media  will  be  accessible  at  least  $0v  of  the 
time. 


3. 1.4.3  Communications  Hardware. 

a.  Modems: 


(1)  Limited  Distance  Modems.  For  on-base  use,  limited  distance  modems  are 
required.  The  modems  must  be  capable  of  operating  over  standard 
non-conditioned  voice  grade  telephone  lines  at  distances  of  at  least  6 
miles.  The  following  characteristics  are  provided: 

(a)  Switchable  and  capable  of  transmitting  and  receiving  aata  at  9600 
bits  per  second  (bps)  up  to  6  miles  and  19,200  bps  up  to  3  miles. 

(b)  The  limited  distance  modem  shall  meet  E1A  btanaard 

EIA-R S-232-C/CC1TT  Recommendation  V.24  for  interfacing  with 
external  equipment. 


(2)  Long  Distance  Modems.  Modems  used  outside  the  United  States  (Europe, 
Asia)  on  non-conditioned  commercial  telephone  lines.  The  modem  is  a 
CODEX/V.29  data  modem  model  21962  and  must  be  homologated  (PTT 
option)  to  the  country  where  the  system  is  installed.  The  CODEX 
Universal  PTT  option,  Product  code  22120,  is  provided  when  required. 

b.  Line  Drivers.  Line  drivers  are  required  to  boost  the  electronic  signal  for 
communications  between  modems  and  CRTs  over  long  distances  (i.e.,  75  feet  or 
more). 

c.  Encryption  Devices.  NSA-endorsed  Data  Encryption  Standard  (DES)  devices  are 
required.  (Functionality  may  be  combined  for  encryption  devices  and  long  or 
limited  distance  modems.) 


3.1.5  Environment  and  Physical  Facilities.  AF1RMS  equipment  must  operate  throughout 
the  ranges  of  electrical  power  and  environmental  tolerances  stated  below. 


3. 1.5.1  Space. 


(1)  Site  Locations.  Systems  are  installed  at  various  Air  Force  installations 
worldwide.  The  central  node  location  space  ranges  from  a  maximum  20  square 
feet  for  the  smallest  configuration  to  a  maximum  of  200  square  feet  for  the 
largest  configuration. 

(2)  Flooring.  Equipment  does  not  require  raised  flooring.  The  flooring  may  be 
carpeted.  There  are  no  special  static  control  facilities. 

(3)  Ceiling  Height.  The  distance  from  the  floor  surface  to  the  unobstructed  ceiling 
is  at  least  &  feet. 

(4)  Access  Route.  Equipment  is  installed  in  office  buildings  with  access  being  the 
size  of  a  normal  office  doorway.  Some  facilities  are  established  computer 
facilities  with  a  double  door  access  route. 


3. 1.5.2  Electrical  Power.  All  equipment  must  be  capable  of  operating  within  the 
requirements  of  MIL-E-4158  and  is  further  defined  by  the  following: 


(1)  Voltage  regulation  steady  state 

(2)  Voltage  disturbances 
Momentary  undervoltage 

Transient  overvoltage 

Surges 


+  10%  to 


-15% 


30%  for  less  than  0.5  seconds 
-100%  acceptable  to  20  milliseconds 

200%  for  less  than  0.2  milliseconds 

IAW  IEEE  587-1980 
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(3) 

Voltage  harmonic  distortion 

+  3"L  -5ib  (with  linear  load) 

(4) 

Frequency  variation 

5Q/60Hz  plus  or  minus  1  Hz 

(5) 

Frequency  variation  rate  of  change 

1  Hz/second 

(6) 

Power  factor 

0.8 

(7) 

220/240  Volts  +or-10'iL  single  phase,  2 

wire 

(S) 

105  Volts  +or-109s>  single  phase,  2  wire 

(Japan) 

In  addition  to  characteristics  1-8  above,  it  is  desirable  that  deployable  equipment 
operate  using  an  Air  Force  25KVA  generator  and  that  the  equipment  be  ruggedized  (for 
handling,  ground  transportation,  and  air  transport)  in  accordance  with  MIL-STD-810.  An 
electrical  power  fault  detection  device  is  required  to  prevent  equipment  failure  (e.g.,  disk 
head  crash). 

3. 1.5.3  Air  Conditioning.  The  ambient  temperature  is  maintained  by  the  U.S.  government 
between  60  and  90  degrees  F  with  a  relative  humidity  of  between  20  and  90  percent, 
non-condensing.  No  special  dust,  static  electricity  control,  or  chilled  water  facilities  are 
available.  The  computer  is  integrated  with  the  A/C  system  to  provide  automatic  thermal 
shutdown  to  prevent  equipment  failure  during  high  or  low  temperature  situations. 

3. 1.5.4  Remote  Locations.  Remote  equipment  is  installed  in  various  environments  within 
LI. 5.  Air  Force  organizations.  Terminals,  office  printers,  and  modems  fit  on  normal  table 
tops  or  desk  surfaces. 

3. 1.5.5  TEMPEST  Requirement.  All  equipment,  connectors,  and  cabling  that  convey 
classified  information  must  meet  the  limits  specified  in  NACSIM  5100A.  All  equipment 
must  be  on  the  Preferred  Products  List  (PPL)  or  approved  by  AFCSC/EPV  San  Antonio, 

TX  7824  3. 


3.2  Support  Software  Environment.  AFIRMS  software  is  broken  up  into  two  general 
categories:  Applications  Software  and  Support  Software.  Applications  Software  is  that 
software  which  applies  specified  algorithms  to  a  given  data  set,  and/or 
stores/retrieves/formats/analyzes/dispLys  a  given  set  of  data.  Applications  software 
programs/algorithms  are  enumerated  and  defined  in  the  AFIRMS  Transforms  and  Models 
Document,  and  in  each  of  the  AFIRMS  Subsystem  Specifications.  This  section  enumerates 
and  defines  the  elements  of  support  software  required  to  create  the  environment 
necessary  to  support  AFIRMS'  general  functionality  and  the  AFIRMS  Applications 
Software. 


3.2.1  Central  Node  Support  Software.  Each  AFIRMS  Central  Node  requires  the  support 
software  listed  in  this  section. 


3.2. 1.1  Operating  System.  A  general  purpose  operating  system  is  required  to  provide  file 
access,  program  control,  and  data  communications'  interfaces.  In  addition,  operating 
system  operation  (e.g.,  device  I/O)  does  not  impact  the  timing  and  flexibility  (Ref.  section 
2.3)  of  AFIRMS  operational  software.  The  operating  system  must  be  able  to: 


a.  Concurrently  process  a  combination  of  interactive  and  local  batch  processing. 

d.  Support  a  multi-programming  and  virtual  memory  environment. 

c.  Support  both  file  and  record  level  locking  protection  capability. 

d.  Provide  control  over  all  hardware  and  software. 


e.  Support  logical  as  well  as  physical  mode  access  to  all  system  peripheral  devices 
including  terminals. 

f.  tie  capable  of  detecting  and  marking  bad  blocks  while  formatting  system  and 
data  disks  as  well  as  during  normal  operation. 


g.  Support  up  to  X  concurrent  interactive  users  in  a  minimum  configuration  and  up 
to  20  concurrent  interactive  users  in  a  maximum  configuration. 

h.  Detect  and  automatically  LOGOFF  terminals  which  have  been  inactive  tor  a 
user  definaDle  period  of  time.  This  time  shall  be  determined  and  set  by  the 
system  monitor. 


32031 


3-12 


1. 


Provide  access  to  a  calendar  clock  which  provides  the  calendar  date  and  time 
with  a  resolution  of  one  microsecond  (for  purposes  of  statistical  performance 
analysis  data  collection)  showing  hours,  minutes,  and  seconds  for  time;  and  day, 
month,  and  year  for  date.  This  calendar  clock  shall  be  accessible  to  all 
programming  languages. 

).  Detect  and  terminate  attempts  to  read  or  write  outside  of  any  programs 
allocated  memory  and  detect  and  terminate  attempts  by  any  applications 
program  to  execute  privileged  and  undefined  instructions. 

k.  Provide  High  Order  Language  (HOL)  Run-Time  support  for  I/O,  scheduling,  and 
inter-process/intersite  communication  and  coordination. 

l.  Provide  memory  fault  detection  and  recovery  capabilities. 

m.  Support  high  level  control  of  interrupt  detection,  definition,  and  processing 
activities. 

n.  Provide  the  capability  to  perform  dynamic  load  analysis  and  reporting. 

o.  Provide  host  language  interfaces  (system  directives)  to  system  functions. 


3.2. 1.2  Utility  Routines.  The  following  utility  routines  are  required: 


a.  File  Management  System 

b.  Sort  and  Merge  Utility 

c.  Translation  Utility  (character  code  conversion,  e.g.  ASCII  to  EBCDIC  and 
vice-versa) 

d.  Save  and  Restore  Utility  (to  and  from  tape) 

e.  Security  Utility  (Error  surveillance  and  alerts,  to  recognize,  record  and  indicate 
misuse,  and  attempted  misuse,  of  the  system) 

f.  Logging/Accounting  Utility  (An  automated  audit  trail  will  show:  access  made 
to  files;  how,  and  from  where  the  access  was  initiated;  the  identity  of  the 
person  or  process  that  initiated  the  access;  and  all  unauthorized  attempts.) 

g.  Diagnostic  Software 

h.  Mail  Utility. 
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3.2. 1.3  Communications  Software.  The  specific  requirements  for  communications 
software  will  be  determiner)  during  the  analysis  phase  that  precedes  implementation  at 
each  site.  However,  at  a  minimum,  a  host  interface  to  the  Defense  Data  Network  (DDN) 
is  required  for  each  AFIRMS  site.  This  interface  implements  the  full  DDN  protocol  suite, 
and  supports  site-to-site  communications  over  the  DDN,  and  provides  the  standard  DDN 
services  of  terminal-to-host  communications,  file  transfer,  and  electronic  mail  to  users  of 
the  AFIRMS  system.  Connection  to  the  DDN  is  via  the  ARPANET  network  access 
protocols  or  X.2  5.  Host-to-host  communication  is  via  the  Transmission  Control  Protocol 
(TCP),  MIL-STD  177S,  and  Internet  Protocol  (IP),  MIL-STD  1777.  The  services  which  are 
supported  are  TELNET,  File  Transfer  Protocol  (FTP),  and  the  Simple  Mail  Transfer 
Protocol  (SMT P). 

It  is  recognized  that  normal  DDN  encryption  services  are  limited  to  SECRET  security 
classifications.  However,  with  the  acquisition  of  TOP  SECRET  security  classification 
encryption  devices,  the  DDN  can  be  accessed  for  transmission  of  TOP  SECRET 
information. 


3.2. 1.4  Database  Management  System  (DBMS)  Requirement.  The  AFIRMS  DBMS 
performs  functions  such  as  opening  and  closing  the  database,  transaction  flow,  handling  of 
the  DBMS  Command  Language  requests,  transaction  parsing,  and  automatic  editing  on 
input.  The  DBMS  performs  the  action  of  retrieving  a  record  from  a  file,  writing  a  record 
to  a  file,  and  deleting  and  creating  records  in  a  file.  In  addition,  the  DBMS  allows  for  host 
language  interfaces;  save/restoration  of  full/partial  database  images;  restart/recovery 
capability  with  multi-user/multi-thread  concurrency  controls;  and  some  level  of 
distributed  data  management  synchronization/concurrency  controls.  The  specific  level  of 
distributed  data  synchronization  control  required  will  be  determined  during  the  analysis 
pnase  that  precedes  implementation  at  each  site. 


For  detailed  required  AFIRMS  DBMS  capabilities,  please  reference  the  AFIRMS 
Database  Specification. 
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In  addition  to  the  software  that  comprises  the  AFIRMS  DBMS,  there  is  a  requirement 
for  a  software  package  to  serve/support  the  DBMS  in  the  following  manner: 

a.  Controls  entry  to/exit  from  DBMS  functions. 

b.  Provides  a  link/connection  between  the  communications  software  and  the  DBMS. 

c.  Handles  data  retrieval  and  data  update  transactions. 

d.  Generates  a  waiting  queue  for  transaction  handling  by  transaction  priority. 

e.  Performs  update  notifications  to  other  sites  for  data  changes  (deletions, 
additions  or  modifications)  in  intersite  data  sets. 

f.  Determines  whether  data  retrieval  and  update  transactions  are  to  be 
directed/routed  to  the  local  (functional  area)  database  or  the  central  database. 

g.  Provides  a  link  between  parameter  screen  software  and  the  DBMS  in  order  to 
verify  the  validity  of  parameter  selections. 

3.2.2  Functional  Area  Support  Software.  Each  AFIRMS  functional  area  requires  the 
support  software  enumerated  in  this  section. 

3.2.2. 1  Operating  System.  A  general  purpose  operating  system  is  required  to  provide  file 
access,  program  control,  and  data  communications'  interfaces.  The  operating  system 
must  operate  independent  of  the  existence  of  another  operating  system.  In  addition, 
operating  system  operation  (i.e.,  device  I/O)  does  not  impact  the  timing  and  flexibility  of 
AFIRMS  operational  software.  The  operating  system  must  be  able  to: 

a.  Concurrently  process  a  combination  of  interactive  and  local  batch  processing. 

b.  Support  a  multi-tasking  environment. 

c.  Support  both  record  level  and  file  locking  protection  capability. 

d.  Provide  control  over  all  hardware  and  software. 


e. 


Support  logical  as  well  as  physical  mode  access  to  all  system  peripheral  devices 
including  terminals. 

Support  interactive  processing. 


g.  Be  capable  of  detecting  and  marking  bad  blocks  while  formatting  system  and 
data  disks. 

h.  Support  1  concurrent  interactive  user  in  a  minimum  configuration  and  up  to  3 
concurrent  interactive  users  in  a  maximum  configuration. 

i.  Detect  and  automatically  LOGOFF  terminals  which  have  been  inactive  for  a 
user  definable  period  of  time.  This  time  shall  be  determined  and  set  by  the 
system  monitor. 

j.  Provide  access  to  a  calendar  clock  which  provides  the  calendar  date  and  time 
with  a  resolution  of  one  microsecond  (for  purposes  of  statistical  performance 
analysis  data  collection)  showing  hours,  minutes,  and  seconds  for  time;  and  day, 
month,  and  year  for  date.  This  calendar  clock  shall  be  accessible  to  all 
programming  languages. 

k.  Detect  and  terminate  attempts  to  read  or  write  outside  of  any  programs 
allocated  memory  and  detect  and  terminate  attempts  by  any  applications 
program  to  execute  privileged  and  undefined  instructions. 


3.2.2.2  Utility  Routines.  The  following  utility  routines  are  required: 


a.  File  Management  System 

b.  Sort  and  Merge  Utility 

c.  Translation  Utility  (character  code  conversion,  e.g.  ASCII  to  EBCDIC  and 
vice-versa) 

d.  Save  and  Restore  Utility 

e.  Security  Utility  (Error  surveillance  and  alerts,  to  recognize,  record  and  indicate 
misuse  of  the  system) 

f.  Logging/ Accounting  Utility  (An  automated  audit  trail  will  show:  access  made 
to  files;  how,  and  from  where  the  access  was  initiated;  the  identity  of  the 
person  or  process  that  initiated  the  access;  and  all  unauthorized  attempts.) 

g.  Diagnostic  Software 

h.  Mail  Utility. 
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3. 2.2.3  Communications  Software.  The  specific  requirements  for  communications 
software  will  be  determined  during  the  analysis  phase  that  precedes  implementation  at 
eacn  site.  Communications  between  the  CNM  and  the  intelligent  FA  terminals  must  be 
accommodated  via  some  communications  protocol  supported  on  both  processors.  The 
volume  and  frequency  of  the  various  information  gateways  are  presented  by  functional 
area  in  the  AFIRMS  HQ  USAFE  Database  Specification. 

3. 2.2. 4  Database  Management  System  (DBMS)  Requirement.  The  AFIRMS  DBMS 
performs  functions  such  as  opening  and  closing  the  database,  transaction  flow,  handling  of 
the  DBMS  Command  Language  requests,  transaction  parsing,  and  automatic  editing  on 
input.  The  DBMS  performs  the  action  of  getting/retrieving  a  record  from  a  file,  writing  a 
record  to  a  file,  and  deleting  and  creating  records  in  a  file.  In  addition,  the  DBMS  allows 
for  host  language  interfaces;  save/restoration  of  full/partial  database  images; 
restart/recovery  capability  with  multi-user/multi-thread  concurrency  controls;  and  some 
level  of  distributed  data  management/synchronization/concurrency  controls.  The  specific 
level  of  distributed  data  synchronization  control  required  will  be  determined  during  the 
analysis  phase  that  precedes  implementation  at  each  site. 

For  detailed  required  AFIRMS  DBMS  capabilities,  please  reference  the  AFIRMS 
CSAFE  Database  Specification. 

In  addition  to  the  software  that  comprises  the  AFIRMS  DBMS,  there  is  a  requirement 
for  a  software  package  to  serve/support  the  DBMS  in  the  following  manner: 

a.  Controls  entry  to/exit  from  DBMS  functions. 

b.  Provides  a  link/connection  between  the  communications  software  and  the  DBMS. 

c.  Handles  data  retrieval  and  data  update  transactions. 

d.  Generates  a  waiting  queue  for  transaction  handling  by  transaction  priority. 

e.  Performs  update  notifications  to  other  sites  for  data  changes  (deletions, 
additions  or  modifications)  in  a  DBMS  file. 

f.  Determines  whether  data  retrieval  and  update  transactions  are  to  be 
directed/routed  to  the  local  (functional  area)  database  or  the  central  database. 

8- 


Provides  a  link  between  parameter  screen  software  and  the  DBMS  in  order  to 
verify  the  validity  of  parameter  selections. 
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method  of  display:  graphic,  tabular,  and  integrated  graphic  and  tabular.  The  tabular 
screens  actually  show  the  data  value  and  are  listed  in  table  format,  i.e.,  rows  and 
columns.  The  tabular  screens  may  use  color  to  segregate  the  data  into  like  types  to  assist 
the  user  in  assimilating  the  information.  The  tabular  screens  use  colors  to  highlight  a  line 
and/or  field  as  a  screen  place  marker  for  the  user. 


The  graphic  screens  are  also  of  standard  types:  bar  graph,  line  graph,  and  pictoral 
(i.e.,  maps).  Typically,  these  are  output  screens  only  (they  cannot  be  updated  through  the 
screen).  The  bar  graph  screens  also  have  a  data  value  on  top  of  a  bar  graph. 


The  display  screen  generation  software  must  have  routines  to  generate  these 
screens.  In  summary,  the  generalized  routines  and  particular  features  are: 

a.  Tabular  Screen  Generator: 

(1)  Right  justified  numeric  data. 

(2)  Left  justified  alphanumeric  data. 

(3)  Line  highlighter  that  can  be  toggled  on  and  off. 

(4)  Field  highlighter  that  can  be  toggled  on  and  off. 

(5)  Screen  editor  (for  extensive  data  input  and  editing  capability). 

(6)  Linkable  to  a  special  (nonstandard)  display  area  on  the  screen. 

(7)  Variable  legends. 

(8)  Blanking  of  repeating  column  data  (switchable  on  or  off). 

(9)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  or  some  other 
indicator)  a  row  or  column  of  data  that  has  changed  from  an  original  or 
previous  data  set.  The  means  by  which  this  "data  change  indicator"  is 
activated  will  be  defined  during  the  analysis  phase  that  precedes 
implementation. 

(10)  Field  and  row  coloring  depending  on  value  of  data  field  (selectable). 

(1  l)  Column  headings  programmable  separately  from  body  of  table. 

(12)  Non-sequential  vertical  paging  (up/reverse,  down/forward)  as  well  as 
horizontal  paging  (i.e.,  virtual  screen)  capability. 

( 1  3)  Scrolling  (left,  right,  up,  down)  to  augment  the  paging  feature. 


(14)  Capability  to  generate  a  hard  copy  from  a  screen  display  without  using  a  , 

system  printer. 

(15)  Data  error  checking  and  validation  capabilities  to  include  checking  of 

input  data  for  proper  legal  values,  length  and  format,  as  well  as  upper  and 

lower  case  and  special  character  recognition. 

(16)  Grid  generation. 

(17)  Title,  subtitle,  and  heading  generation. 

(IS)  Dynamic  horizontal/vertical  field  count/sum. 

Graphic  Screen  Generator: 

(1)  Standard  Line  Graph  with  dynamic  or  variable  legend 

(a)  Variable  legends. 

(b)  Automatic  X-  and  Y-axis  scaling. 

(c)  Y-axis  rescaling  after  screen  display. 

(d)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  or  some 
other  indicator)  data  that  has  changed  from  an  original  or  previous 
data  set.  The  means  by  which  this  "data  change  indicator"  is 
activated  will  be  defined  during  the  analysis  phase  that  precedes 
implementation. 

(e)  Field  coloring  depending  on  value  of  data  field  (selectable). 

(f)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

(2)  Standard  Bar  Graph: 

(a)  Variable  legends. 

(b)  Automatic  Y-axis  scaling  (Bar  graph). 

(c)  Automatic  X-axis  scaling  (Bar  graph). 

(d)  Y-axis  rescaling  after  screen  display. 

(e)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  or  some 
other  indicator)  data  that  has  changed  from  an  original  or  previous 
data  set.  The  means  by  which  this  "data  change  indicator"  is 
activated  will  be  defined  during  the  analysis  phase  that  precedes 
implementation. 

(f)  Field  coloring  depending  on  value  of  data  field  (selectable). 

(g)  Capability  to  generate  a  hard  copy  from  a  screen  display. 


(3)  .Standard  Map  Maker  with: 

(a)  Linkable  to  a  special  (nonstandard)  area  on  the  screen  to  display 
remarks  or  other  data  relevant  to  the  display.  This  requires  the 
routine  to  know  where  the  cursor  is  on  the  display  in  order  to  call  up 
the  correct  information. 

(b)  Coordinate  system  so  air  bases  can  be  inserted,  labeled,  and  deleted 
by  a  nontechnical  user  using  latitude  and  longitude  or  CEOREF  map 
coordinates  (the  positioning  will  be  reasonably  accurate  with 
relation  to  one  another). 

(c)  Base  position  is  colored  according  to  a  dynamic  database  value 
(color  indicates  a  condition  or  status). 

(d)  Change  indication  for  positions  whose  values  have  changed. 

(e)  Continuously  variable  software  zoom  (if  not  a  hardware  capability). 

(f)  The  capability  to  generate  and  display  special  symbols. 

Display  Screen  Parameter  Software  as  follows: 

(1)  The  parameter  software  interacts  with  the  AFIRMS  database,  when 
necessary,  to  determine,  self-generate,  and  list  the  appropriate  parameter 
choices  for  the  database  set  requested.  For  example,  if  ATO  3  (the 
specified  database  set)  does  not  have  CBU-52  munitions  (a  parameter 
selection)  tasked,  then  the  list  of  choices  for  a  munition  type  (the 
parameter)  will  not  include  CBU-52. 

(2)  The  parameter  software  must  be  interpretive,  so  as  to: 

(a)  Ensure  a  consistent  and  well  defined  interface  to  the  database 
transaction  software 

(b)  Provide  a  flexible  and  friendly  mechanism  for  user  input. 

(3)  The  parameter  software  also  permits  write-in  choices  where  appropriate. 
In  some  instances,  it  isn't  possible  or  practical  to  list  all  appropriate 
parameter  selections. 

Function  Keys.  AFIRMS  is  operated  by  the  user  using  a  system  of  menus  and 
function  keys.  Some  of  the  product  screen  keys  can  be  seen  at  the  bottom  of 
the  display  screens  described  in  the  AFIRMS  Product  Description  annexes.  The 
number  of  available  keys  is  less  than  the  number  of  keys  needed;  arrays  of  keys 
are  utilized  to  overcome  that  problem. 

The  first  array  contains  the  basic  key  functions  needed  for  every  display  screen. 
Except  for  the  Base  Status  Map,  the  graphic  displays  require  only  the  first 
array.  The  tabular  input  screens  require  key  functions  to  add,  delete  and 
change/edit  data.  A  paging  and/or  scrolling  capability  is  needed.  Because  some 
records  have  sub-records  (e.g.,  a  wing  with  several  munitions  as  the  Wing 
Resource  Summary  product,  a  mission  with  two  MDSs  and/or  aircralt  SCLs  as 


the  Tasking  Information  product,  or  a  unit  at  multiple  locations  or  with  multiple 
MDSs  as  the  Unit  Status  product),  the  system  must  know  when  it  is  editing 
records  or  sub-records.  Therefore,  the  second  array  is  reserved  for  editing 
records  and  the  third  array  is  reserved  for  editing  sub-records.  Switching 
between  arrays  is  done  with  two  special  function  keys.  An  arrow  on  either  or 
both  ends  (if  on  the  2nd  of  3  arrays)  tells  the  user  which  array  is  in  use.  The 
required  functions  of  these  keys  are  outlined  in  Table  3-1. 


3.3  Interfaces.  AFIRMS  consists  of  a  set  of  subsystem  sites  requiring  data  transfer 
between  them.  In  addition,  AFIRMS  Will  interface  with  selected  existing  or  future 
systems.  This  section  describes  the  three  basic  kinds  of  AFIRMS  system  interface 
requirements,  i.e.  intersite,  intrasite,  and  external  interfaces. 


3.3.1  AFIRMS  Intersite  Interfaces.  The  AFIRMS  intersite  interfaces  include  all  those 
required  for  transmission  and  receipt  of  data  between  two  or  more  AFIRMS  sites. 


3.3. 1.1  Intersite  Transaction  Header.  Each  transaction  sent  between  AFIRMS  sites  has  a 
common  transaction  header.  This  header  is  composed  of: 

a.  Transaction  ID 

b.  Transaction  Type 

c.  Origination  Address 

d.  Destination  Address 

e.  Total  Length  of  Transaction 

f.  Priority  Transmission  Indicator 

The  specification  for  this  header  is  defined  in  Appendix  A. 


3.3. 1.2  Intersite  Transaction  Data.  AFIRMS  uses  consistent  format  for  transmission  of 
data  between  sites.  Each  transmission  consists  of  the  AFIRMS  header  mentioned  above 
and  the  transaction  data  format.  The  transaction  types  supported  by  AFIRMS  are: 


a.  Ease  Status  Transmission  Request 

b.  Unit  Transmission  R equest 

c.  Resource  Summary  Transmission  Request 
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Table  3-1 


PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION 


Key  No. 

Key  Label 

Key  Function  Description 

1st  Array: 

1 

DISPLAY 

PARAM 

SELECT 

Takes  the  user  back  to  the  parameter 
selection  screen.  The  parameter  choices 
the  user  made  to  display  the  product  are 
redisplayed. 

2 

LINE 

HIGHLIGHT 

T  OG  GL  E 

Changes  the  state  of  the  Line 

Highlighter  toggle.  If  it  is 
turned/toggled  OFF,  the  state  is  changed  to 

ON  and  the  Line  Highlighter  appears.  If  it  is 
toggled  ON,  the  state  is  changed  to  OFF  and 
the  Line  Highlighter  is  removed  from  the 
tabular  display.  The  key  is  not  active  when  a 
graphic  screen  is  displayed. 

3 

HARD 

COPY 

Spawns  a  batch  process  to  print  a  color 
copy  of  the  display.  This  key  is  on  the  1st 
array  only  if  the  product  has  a  single  screen 
display.  For  multiscreen  displays,  the  key  is 
on  the  2nd  array  with  the  paging  keys. 

'4 

TOP 

MENU 

Returns  the  user  to  the  first/top  menu. 

5 

PREVIOUS 

MENU 

Returns  the  user  to  the  menu  from  which 
the  product  was  selected. 

6 

HELP 

Interrupts  the  product  display  and  takes  the 
user  to  the  HELP  screen.  When  finished  with 
the  HELP  screen,  the  user  returns  to  this 
display. 

7 

UPDATE 

SCREEN 

Causes  the  system  to  refresh  or  update 
the  product  display  using  the  current 
parameter  choices.  Normally  used  with  a 
resource  status  product  when  the  system 
notifies  the  user  that  the  status  data  has 
been  updated. 

S 

Not  used. 

Table  3-1 


PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION  (Cont.) 


t  , 


Key  No. 

Key  Label 

Key  Function  Description 

2nd  array: 

9 

PAGE 

REVERSE 

Page  the  product  in  reverse  order.  It 
pages  a  full  or  half  page  at  a  time,  depending 
on  the  paging  option  selected.  It  is  active 
only  when  a  tabular  product  is  displayed  and 
is  longer  than  one  page  of  display. 

10 

FULL  PG 

HALF  PG 

Changes  the  paging  state  to  FULL  or  HALF 
paging,  depending  on  the  current  state.  The 
current  paging  state  is  always  highlighted  or 
colored. 

1  l 

PAGE 

FORWARD 

Causes  the  system  to  page  the  product 
forward  in  sequential  order.  It  pages  a  full  or 
half  page  at  a  time,  depending  on  the  paging 
option  selected.  It  is  active  only  as  described 
in  PAGE  REVERSE  above. 

12 

CHANGE 

XXXXXX 

DATA 

Permits  editing  of  the  screen  data.  The 
'XXXXXX'  is  changed  to  the  appropriate 
term  (such  as  aircraft  or  aircrew)  when  the 
product  is  designed.  Used  only  for  tabular 
products.  Pressing  the  key  a  second  time 
de-activates  the  CHANGE  mode. 

13 

ADD 

XXXXXX 

DATA 

Permits  the  addition  of  a  record  to  the 
database.  Used  only  for  tabular 
products.  Pressing  the  key  a  second  time 
de-activates  the  ADD  mode. 

14 

DELETE 

XXXXXX 

DATA 

Permits  the  deletion  of  a  record  from 
the  database.  Used  only  tor  tabular 
products.  Pressing  the  key  a  second  time 
de-activates  the  DELETE  mode. 

1  5 

HARD 

COPY 

Same  as  3  above. 

16 

ENTER 

Updates  the  data  base  as  directed  by  keys  12, 

1  3,  and  14  above.  The  ENTER  key  acts  as  a 
confirmation  step  for  the 
CHANGE/ADD/DELETE  keys. 
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Table  3-1 


PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION  (Cont.) 


Key  No. 

Key  Label 

Key  Function  Description 

17 

INTERROGATE 

BASE 

Interrogates  the  cursor  position  and 
displays  a  box  containing  data  corresponding  to 
the  base  displayed  under  the  cursor  (see  Base 
Status  Map).  It  occupies  one  of  the  9-16  key 
positions. 

IS 

DELETE 

DATA 

BOX 

Deletes  the  box  containing  the  base 
data.  It  occupies  one  of  the  9-16 
key  positions. 

19 

SCALE 

UP 

Increases  the  y-axis  scale  of  the  bar 
graph  by  approximately  100%  after  the  screen  is 
displayed.  It  occupies  one  of  the  9-16  key 
positions.  Used  with  bar  graphs  only. 

20 

SCALE 

DOWN 

Decreases  the  y-axis  scale  of  the  bar 
graph  by  approximately  50%  after  the  screen  is 
displayed.  It  replaces  one  of  the  9-16  key 
positions.  Used  with  bar  graphs  only. 

3rd  array: 

21 

PAGE 

REVERSE 

Same  as  9  above. 

22 

FULL  PG 

HALF  PG 

Same  as  10  above. 

23 

PAGE 

FORWARD 

Same  as  1 1  above. 

24 

CHANGE 

XXXXXX 

DATA 

Same  as  12  above  except  only  sub-record 
data  is  changed.  The  system  prevents 
changes  to  record  keys/data. 

25 

ADD 

XXXXXX 

DATA 

Same  as  13  above  except  able  to  add 
sub-records  only. 

26 

DELETE 

XXXXXX 

DATA 

Same  as  14  above  except  able  to  delete 
sub-records  only. 

27 

Not  used. 

2X 

ENTER 

Same  as  16  aoove. 
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d.  Base  Status  Transmission 

e.  Unit  Status  Transmission 

{.  Resource  Summary  Transmission 

g.  Transaction  Cancellation  Request 

h.  Transmission  Restart  Request 

Specifications  for  Base  Status,  Unit  Status  and  Resource  Summary  Transmissions  are 
defined  in  Appendix  A. 


3.3.2  AFIRMS  Intrasite  Interfaces.  The  transactions  that  occur  within  a  particular  site 
are  defined  in  the  various  subsystem  specifications.  However,  since  each  site,  even  within 
a  particular  subsystem,  may  be  configured  in  a  significantly  different  manner,  this  section 
identifies  the  intrasite  interfaces  required. 


3.3.3  External  System  Interfaces.  It  is  the  goal/intent  of  AFIRMS  to  avoid  data 
collection  redundancy  where  possible.  AFIRMS  accomplishes  this  by  interfacing  with 
current  or  projected  systems  that  contain  the  accurate  data  required.  AFIRMS  takes 
advantage  of  other  functional  systems  that  address  capability  assessments  for  a  subset  of 
the  resources  which  AFIRMS  uses  to  provide  its  integrated  capability  assessments.  In 
order  to  handle  interfaces  with  future  developing  systems,  AFIRMS  is  designed  using 
generic  interfaces.  This  allows  for  the  inclusion  of  interfaces  with  future  systems  over 
time  with  minimal  modification  to  the  AFIRMS  system. 


3.3.3. 1  General  Interface  Specifications.  AFIRMS  must  interface  with  systems  that  will 
be  implemented  in  the  future.  To  facilitate  future  interfaces,  AFIRMS  employs 
generalized  interface  formats.  Refer  to  section  2.3  of  this  document  for  a  more  in-depth 
discussion  of  the  generalized  interface  specifications  for  AFIRMS.  These  intersite 
interface  specifications  are  made  up  of  primary  and  secondary  information  flows.  They 
provide  enhanced  system  flexibility,  availability  and  capability  to  assimilate  information 
from  heterogeneous  hardware  within  the  AFIRMS  system  and  from  external  systems. 
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3. 3. 3. 2  Specific  External  System  Interfaces.  The  following  systems  are  the 
top  candidates  for  interfacing  with  AFIRMS  for  the  purpose  of  receiving  and/or 
sending  common  data: 

a.  Air  Force  Operations  Resource  Management  System  (AFORMS) 

b.  Core  Automated  Maintenance  System  (CAMS) 

c.  Combat  Ammunition  System  (CAS) 

d.  Combat  Fuels  Management  System  (CFMS) 

e.  Combat  Supplies  Management  System  (CSMS) 

f.  Contingency  Operation/Mobility  Planning  and  Execution  System  (COMPES) 

g.  Logistics  Capability  Measurement  System  (LCMS) 

h.  War  Mobilization  Plan  Updating  System  Weapon  System  Management 
Information  System  (WSMIS) 

i.  Combat  Supply  Systems  (CSS) 

j.  Vehicle  Integrated  Management  System  (VIMS) 

k.  Airlift  Implementation  and  Monitoring  System  (AIMS);  MAC-unique  system 

l.  Military  Air  Integrated  Reporting  System  (MAIRS);  MAC-unique  system 

m.  Information  Processing  system  (IPS);  MAC-unique  system 

n.  Flow  Generator,  Version  3  (FLOGEN  III);  MAC-unique  system 

o.  Airlift  Deployment  Analysis  System  (ADANS);  MAC-unique  system 

p.  Theatre  Airlift  Management  System  (TAMS);  MAC-unique  system 

q.  Force  Management  Information  System  (FMIS);  SAC-unique  system 

3.4  Security.  The  AFIRMS  ADPS  handles  data  up  to  and  including  TOP  SECRET 
classification  level.  It  handles  sensitive  unclassified  data.  Due  to  the 
various  environments  and  processing  requirements  at  the  wing,  MAJCOM  and  HQ 
USAF  levels  of  operations,  the  security  modes  of  operations  differ  as  follows: 
HQ  USAF  operates  in  the  TOP  SECRET  System  High  Security  mode;  MAJCOMs  operate 
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in  the  TOP  SECRET  System  High  Security  Mode;  and  WINGs  operate  in  the 
Controlled  Security  mode  at  levels  of  classification  from  unclassified  through 
SECRET. 


Security  protection  is  provided  for  these  environments  by  utilizing  a 
combination  of  the  following  security  measures  in  accordance  with  AFR  205-16. 


a.  Personnel  Security.  A  personnel  security  program  is  implemented  for 
the  AFIRMS  program  in  accordance  with  the  provisions  of  DOD 
Regulation  5200.1/AFR  205-32  USAF  Personnel  Security  Program. 
Personnel  access  control  is  maintained  for  the  central  computer 
facilities  and  remote  terminal  areas. 

(1)  Central  Computer  Facility.  Strict  personnel  access  control 
ensures  that  access  is  only  to  personnel  who  require  it,  and  who 
possess  a  security  clearance  at  least  equal  to  the  highest 
classification  of  information  being  processed  or  openly  stored 
at  the  facility. 

(2)  Remote  Terminal  Area(s).  Authorization  for  access  to  and  use  of 
remote  terminals  devices,  is  based  on  an  individual's  duties, 
his/her  need  to  use  the  terminal,  and  possession  of  a  security 
clearance  of  the  required  level. 
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Physical  Security.  Measures  are  taken  to  ensure  external  protection  for 
A PIR. MS  againstunauthorized  access  to  the  central  computer  facility,  to  the 
system  from  remote  terminals  ana  to  data  storage  media. 

(1)  Central  Computer  Facility.  Central  computer  facility  physical  security  is 
established  in  accordance  with  the  requirements  for  the  highest 
classification  and  data  sensitivity  that  are  associated  with  the  ADPs  or 
openly  stored  data. 

(2)  Remote  Terminal  Area.  Physical  security  measures  at  remote  sites  fulfill 
the  minimum  requirements  for  the  highest  classification  of  information 
accessed  from  or  stored  at  the  site. 

Hardware  Security.  AFIRMS  system  hardware  meets  all  of  the  provisions 
recommended  in  DoD  5200. 28.M,  ADP  Security  Manual  for  hardware  security 
features. 

Software  Security.  The  operating  systems  selected  for  use  conform  to  general 
software  security  requirements  stated  in  DoL)  5200.28M.  In  addition  to  the 
security  protection  features  contained  in  the  operating  systems,  a  combination 
of  system  and  application  software  protection  features  are  utilized  to  provide 
the  following  security  protection  to  comply  with  applicable  DoD  and  Air  Force 
security  policies. 

(1)  Access  Control,  to  prevent  unauthorized  entry  to  systems,  files  and 
programs. 

(2)  Error  Surveillance  and  Alerts,  to  recognize,  record  and  indicate  misuse 
and  attempted  misuse  of  the  system. 

(3)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files.  An 
automated  audit  trail  shows:  accesses  made  to  files;  how,  and  from  where 
the  access  was  initiated;  the  identity  of  the  person  or  process  that 
initiated  the  access;  and  all  unauthorized  attempts. 

System  Stability.  All  AFIRMS  components  operate  so  that  one  can 
automatically  or  administratively  detect  and  report  system  hardware  and 
software  malfunctions  in  time  to  prevent  unauthorized  disclosure. 

Data  Integrity.  Each  database,  file,  and  data  set/element  is  identified  with  an 
origin,  use,  and  an  explicitly  defined  set  of  access  controls.  These  access 
controls  are  based  on  classification,  sensitivity,  user  clearance,  and  established 
need-to-know. 

National  bureau  of  standards  (NBS)  or  National  Security  Agency  (NSA) 
approved  data  encryption  devices  may  be  required  for  transmission  of  sensitive 
unclassified  data  depending  on  nature  of  the  data. 

Emanations  Security  (LMbLC).  ADP  and  communications  equipment  utilized  to 
process  classified  material  at  \FIRMS  sites  will  be  TEMPEST  approved.  -Ml 
devices  that  are  not  TEMPEST  approved  will  be  tested  and  approved  for 
placement  in  the  ADP  facilities  in  such  a  manner  as  to  control  compromising 
emanations.  All  equipment  will  be  installed  lA'X  the  guidelines  stated  in 
NACSIM  5203. 


i.  Procedural  Security.  Security  operating  procedures  meet  the  requirements  ot 
AFR  205-1  and  205-16  and  include  the  following: 

(1)  System  Access  Controls 

(2)  File  Access  Controls 

(3)  Personnel  Access  Controls 

(4)  Security  Markings 

(5)  Protecting  Classified  Output 

(6)  Physical  Security 

(7)  Protection  of  Residual  Information 


3.5  Controls.  The  AFIRMS  system  provides  integrated  control  functions  which  operate  at 
system  levels  independent  of  stated  AFIRMS  operational  functionality.  These  functions 
are  implemented  and  utilized  in  such  a  way  as  to  minimize  their  impact  on  AFIRMS 
execution.  In  each  case,  control  functions  are  logically  apportioned  amongst  the  three 
AFIRMS  subsystem  levels,  with  some  features  available  only  to  users  of  systems  operating 
in  System  High  Security  mode. 

Control  functions  are  logically  separated  into  two  functional  categories: 
System/Operations  Management  Controls,  and  Intersite  Access  and  Data  Flow  Controls. 
Additional  controls  will  be  implemented  at  the  subsystem  level,  and  are  further  discussed 
in  the  AFIRMS  Subsystem  Specifications  documents  (e.g.,  Intrasite  Access  Controls.) 


3.5.1  System/Operations  Management  Controls.  These  incorporate  the  following 

x _ _ 


functions: 


The  application  of  software  monitoring  and  diagnostic  utilities. 

The  application  of  hardware  monitoring  and  diagnostic  utilities. 

The  ability  of  start,  stop,  and  restart  AFIRMS  system  and  communication 
processes,  including  upper  level  control  of  network  performance. 

The  ability  to  alter  AFIRMS  system  runtime  parameters  dynamically  (e.g., 
process  priorities,  operating  system  parameters,  etc.) 
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3.5.2  Intersite  Access  and  Data  Flow  Controls.  Functions  of  this  nature  address  control 
requirements  imposed  by  security  issues.  Additionally,  these  functions  will  assist  in 
supporting  downgraded  operational  modes.  These  include: 

a.  Dynamic  subtraction/addition  of  AF1RMS  sites  from  the  worldwide  AFIRMS 
configuration. 

b.  Dynamic  imposition  of  limitations/new  priorities  on  intersite  data 
communication  to  and/or  from  specific  sites. 


SECTION  4.  DESIGN  DETAILS 


4.1  General  Operating  Procedures.  The  AFIRMS  general  operating  procedures 
with  respect  to  the  load,  start,  stop,  recovery,  and  restart  of  a  particular 
node  and/or  sub-system  are  described  in  the  AFIRMS  Subsystem  Specifications. 
AFIRMS  system  level  operating  procedures  are  functions  which  relate  to  the 
initialization,  termination,  maintenance,  and  security  of  the  AFIRMS  system  as 
a  whole.  Many  of  these  are  enumerated  in  Section  3.5  (Controls).  Additional 
procedures  are: 

a.  Archiving  of  system  diagnostic  information,  and  regular  analysis  and 
time-comparisons  thereof. 

b.  Periodic  modification  of  system  level  passwords  (i.e.,  System 
Manager's),  and  dissemination  throughout  AFIRMS'  security  files. 

c.  Archiving  of  AFIRMS'  network  configurations  for  diagnostic  and 
recovery  purposes. 

d.  Introduction/deletion  of  AFIRMS  nodes. 

e.  Initialization,  termination,  and  diagnostic  maintenance  of  inter-site 
communication  processes  (e.g.,  DECNET). 

f.  Dissemination  of  AFIRMS'  software/data/format  modifications,  and 
specifications  relating  to  each. 

g.  Transmission  and  throughput  analysis  of  test  data  messages  throughout 
the  AFIRMS  System  on  a  daily  basis. 

4.2  System  Logical  Flow.  The  proposed  AFIRMS  information  flow  is  shown  in 
Figures  4-1  and  4-2.  Squadrons  are  linked  hierarchically  to  a  wing  which  may 
be  linked  hierarchically  to  an  Air  Division  (SAC)  or  Airlift  Division  (MAC), 
which  may  be  linked  hierarchically  to  a  NAF  (MAC  and  SAC),  but  which 
ultimately  is  linked  hierarchically  to  a  MAJCOM,  which  in  turn  is  linked  to 
HQ  USAF. 

The  aforementioned  data  flows  are  one-way,  thereby  making  the  system  a 
push  reporting  system  where  data  is  pushed  up  the  hierarchy.  This  push 
approach  is  designed  to  minimize  communication  requirements  and  simplify  the 
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data  synchronization  problem.  Note,  however,  that  the  push  approach  does  not 
prevent  requests  for  standard  data  "pushes"  on  an  exception  basis  in  addition 
to  the  standard  periodic  pushes  of  data.  Additionally,  before  information  is 
passed  to  the  MAJCOM,  a  wing  OPR  can  check  the  data  for  accuracy.  Certain 
controls  or  filters  are  needed  to  prevent  communications  overloads. 
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Figure  4-1.  AF1RMS  Logical  Flow 


4.3  System  Data. 

System  data  storage  requirements  are  specified  in  the  Database  Specifications  for 
each  subsystem.  Data  falls  into  one  of  two  categories:  inputs  and  outputs. 


4.3.1  Inputs.  Input  data  consists  of  data  either  stored  in  the  AF1RMS  database  or 
transmitted  from  one  process  to  another.  These  two  data  categories  are  presentee  in 
detail  in  the  following  documents: 

a.  Input  Records.  Input  record  nomenclature,  source,  expected  volume,  frequency 
priority,  degree  of  sensitivity  and  requirement  for  timeliness  are  described  in 
the  AFIRMS  Data  Requirements  Document  and  Database  Specifications. 


b.  Input  Data  Elements.  Data  elements  definitions  are  provided  in 
AFIRMS  Data  Requirements  Document  and  Database  Specifications. 

c.  Data  request/update  interface  specifications  are  detailed  in  the 
Subsystem  Specifications. 


4.3.2  Outputs.  The  information  in  this  section  is  a  summary  of  the 
information  in  the  same  section  in  the  three  Subsystem  Specifications.  It  is 
presented  here  to  provide  an  overview  of  total  system  functionality. 
Operational  AFIRMS  outputs  include  reports  and  graphic  readiness  measurement 
displays  as  follows: 


a.  Output  Reports.  'FIRMS  repor t/display  outputs  are  fully  described  in 
the  AFIRMS  Product  Descriptions  series.  The  output  reports  are 
graphically  displayed.  These  are  enumerated  in  Table  4-1.  Table  4-1 
provides  a  listing  of  the  AFIRMS  output  reports  developed  for  the 
fighter  mission.  MAJCOMs  will  require  different  types  of  products  to 
support  their  specific  missions.  For  example,  MAC  users  will  require 
output  reports  that  support  the  strategic  and  tactical  airlift 
missions;  SAC  users  will  need  output  reports  that  support  the 
bombardment,  tanker,  and  missile  missions. 

b.  Output  data  interface  specifications  are  detailed  in  the  Subsystem 
Specifications. 

c.  Output  Data  Elements.  Output  data  elements  are  described  in  the 
AFIRMS  Data  Requirements  Document. 

d.  Output  Report  Functional  Area  Users.  AFIRMS  report/display  outputs 
are  enumerated  with  respect  to  primary  and  supporting  users  of  each 
AFIRMS  Subsystem  Specification. 
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TABLE  4-1 


AFIRMS  OUTPUT  REPORT  LISTING 


Screen  Title 

Format 

Est.  Daily 
Volume  it  Freq. 

Complexity 

Classification 

Security 

Aircraft  Sc  Mission  Tasking  Details 

T  abular 

1  pg  (2  5/AF 

1  pg  (2  12/M  A3 

1  pg  (2  5/Wg 

Medium 

U-TS* 

Aircraft  Spares  Support  Capability 

Graphic 

1  pg  (2  1 6/AF 

1  pg  (2  20/M  A3 

1  pg  (26/Wg 

Complex 

U-TS* 

Aircraft  Tasking 

Graphic 

1  pg  (2  5/AF 

1  pg  (2  12/M  A3 

1  pg  (d5/Wg 

Medium 

U-TS* 

Attrition  T rends 

Graphic 

1  pg  (28/AF 

1  pg  (2  8/M  A3 

Simple 

Secret 

Base  Fuels  Capability 

Graphic 

1  pg  (2  16/AF 

1  pg  (2  20/ M A3 

1  pg  (d6/Wg 

Medium 

U-TS* 

Base  Status  (Input) 

T  abular 

16  pg  tdS/AF 

8  pg  (2  16/M  A3 

Simple 

U-S 

Base  Status  (Output) 

Graphic 

16  pg  (28/AF 

8  pg  (cl  16/M  A3 

Simple 

U-S 

Capability  Perspective 

Graphic 

1  pg  (d  2/ AF 

1  pg  (2  2/M  A3 

Complex 

Secret 

Communications  Support  Status 

Graphic 

16  pg  (d  1 6/AF 

8  pg  (2  24/ M A3 

Simple 

U-S 

Fuels  Capability 

Graphic 

1  pg  (2  16/AF 

1  pg  (d  20/M  A3 

Medium 

U-TS* 

Dollars  to  Readiness  -  Comparisons 

Graphic 

1  pg  (d  4/AF 

1  pg  (d  4/M  A3 

Complex 

Secret 

Dollars  to  Readiness  -  Resource 
Perspective 

Graphic 

1  pg  (2 4/AF 

I  pg  (2  4/M  A3 

Complex 

Secret 

Dollars  to  Readiness  Associations 

T  abular 

2  pg  (dS/AF 

1  pg  (d  8/M  A3 

Simple 

Unclas 
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AF1RMS  OUTPUT  REPORT  LISTING  (Continued) 


Screen  Title 

Format 

Est.  Daily 
Volume  <$c  Freq. 

Complexity 

Classification 

Security 

Individual  Resource  Capability 

Graphic 

1  pg  @8/AF 

1  pg  (d  1 2/M  Ad 

1  pg  (d9/Wg 

Complex 

U-TS* 

Integrated  Capability 

Graphic 

1  pg  (d8/AF 

1  pg  @  12/M  a: 

1  pg  @6/Wg 

Complex 

U-TS* 

Mission  Area  Tasking 

Graphic 

1  pg  (d4/AF 

1  pg  (d  4/M  A3 

Medium 

Secret 

Mission  Profile  Definition 

T  abular 

8  pg  (d8/AF 

8  pg  (cl  16/MA3 

3  pg  (d  3/Wg 

Simple 

U-S 

Mission  Tasking 

Graphic 

l  pg  (d  5/AF 

1  pg  (d  12/M  A3 

1  pg  (d5/Wg 

Medium 

U-TS* 

Munitions  Capability 

Graphic 

1  pg  (d  16/AF 

1  pg  ^  20/M  A3 

1  pg  (d6/Wg 

Medium 

U-TS* 

Munitions  Substitution  Sortie 
Capability 

Graphic 

1  pg  (d  4/  A  F 
l  pg  (d  4/M  A3 

Complex 

Secret 

Munitions  Substitution  Sortie 
Requirement 

Graphic 

l  pg  @4/AF 

1  pg  (d  4/M  A3 

Complex 

Secret 

Munitions  Status 

T  abular 

20  pg  (d8/AF 

8  pg  (d  48/M  A3 

Medium 

U-S 

OPlan/OPORD  Associations 

T  abular 

3  pg  (d 8/AF 

3  pg  (d  8/M  A3 

1  pg  (d  1/W  g 

Simple 

Lnc  las 

Order  Assignments 

T  abular 

8  pg  (d8/AF 

8  pg  (d  8/M  A3 

1  pg  (d  l/'Xg 

Simple 

U-S 

Screen  Title 

Format 

Est.  Daily 
Volume  &  Freq. 

Complexity 

Classification 

Security 

Process  Status 

Tabular 

3  pg  @20/ AF 

3  pg  (d2Q/MA3 

1  pg  (d6/Wg 

Simple 

Unclas 

Resource  Reallocation 

Graphic 

1  pg  (d  16/AF 

1  pg  (d  8/M  A3 

Simple 

Secret 

Resource  Unit  Price 

T  abular 

3  pg  @4/AF 

3  pg  @  4/M  A3 

Simple 

Unclas 

Status  Map 

Graphic 

8  pg  (d  16/AF 

3  pg  (d  20/  M  A3 

Simple 

U-S 

Unit  Status  (Input) 

T  abu  lar 

16  pg  (d8/AF 

8  pg  (d  16/M  A3 

Medium 

U-S 

Unit  Status  (Output) 

T  abular 

16  pg  @8/AF 

8  pg  @  16/M  A3 

1  pg  (d65/Wg 

Medium 

U-S 

Wing  Flying  Day 

T  abular 

3  pg  (d4/AF 

3  pg  (d4/MA3 

I  pg  (d  2/Wg 

Simple 

U-S 

Wing  Operations  Rates 

T  abular 

3  pg  (d4/AF 

3  pg  (d4/MA3 

1  pg  (d2/Wg 

Simple 

U-S 

Wing  Resource  Summary 

T  abular 

! 

20  pg  (d8/AF 

20  pg  (d  8/M  A3 

2  pg  (d  2/ Wg 

Medium 

U-S 

Resupply  Schedule 

T  abular 

20  pg  (d4/AF 

20  pg  (d4/MA3 

4  pg  (d 2/Wg 

Simple 

U-S 

TABLE  4-1 


AFIRMS  OUTPUT  REPORT  LISTING  (Continued) 


Screen  Title 

Format 

Est.  Daily 
Volume  6c  Freq. 

Complexity 

Classification 

Security 

MAJCOM  Only 

Attrition  Statistics 

T  abular 

2  pg  (9  1 6/M  A3 

Simple 

Secret 

M1CAP  Forecast 

T  abular 

8  pg  (d  16/MA3 

Medium 

Unclas 

Wing  Only 

AGE  Availability  Status 

T  abular 

2  pg  @  12 

Simple 

Unclas 

AGE  Support  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Aircraft  Availability 

Graphic 

1  pg  @12.5 

Medium 

Conf 

Aircraft  Capability 

Graphic 

1  pg  @  12 

Medium 

Secret 

Aircraft  Status 

Tabular 

6  pg  @  48 1 

Medium 

Unclas 

Aircrew  Availability 

T  abular 

1  pg  @  31 

Medium 

Conf 

Aircrew  Capability 

Graphic 

1  pg  @  12 

Complex 

Secret 

Aircrew  Generation 

Graphic 

1  pg  @  31 

Medium 

Unclas 

Aircrew  Status 

Tabular 

2  pg  @  63 

Simple 

Unclas 

Airfield  Status 

Graphic 

1  pg  @  48 

Simple 

Unclas 

Base  Status  Map 

Graphic 

1  pg  @  48 

Simple 

Unclas 

Base  Status 

T  abular 

3  pg  @  48 

Simple 

Unclas 

Flying  Schedule  (Maintenance) 

T  abular 

6  pg  @  458 

Medium 

Unclas 

Flying  Schedule  (Operations) 

T  abular 

6  pg  @  528 

Medium 

Unclas 

Maintenance  Support  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Mass  Load  Generation  Schedule 

T  abular 

6  pg  @  120 

Simple 

Secret** 

Mission  Flow 

Graphic 

1  pg  @  24 

Medium 

Secret 

Munition  Flow 

Graphic 

1  pg  @  24 

Medium 

Secret 

Munitions  A  6c  D  Availability 

T  abular 

2  pg  @  6 

Simple 

Unclas 

Munitions  Assembly  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Munitions  Availability  Forecast 

Graphic 

1  pg  @  9 

Simple 

Unclas 

Munitions  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Munitions  Distribution  Capability 

Graphic 

1  pg  (d  6 

Medium 

Secret 

Munitions  Load  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Munitions  Load  Crew  Available 

T  abular 

6  pg  @  12 

Simple 

Unclas 

-8 


TABLE  4-1 


AFIRMS  OUTPUT  REPORT  LISTING  (Continued) 


Screen  Title 

Format 

Est.  Daily 
Volume  <5c  Freq. 

Complexity 

Classification 

Security 

Munitions  Load  Crew  Flow 

Graphic 

1  Pg  @  12 

Medium 

Unclas 

Munitions  Status 

T  abular 

3  pg  @  9 

Simple 

Secret 

Fuels  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Fuels  Status 

T  abular 

1  pg  (d  60 

Simple 

Unclas 

Fuels  Status  Map 

Graphic 

1  pg  (d  48 

Simple 

Unclas 

Refueling  Capability 

Graphic 

1  pg  (d  12 

Medium 

Secret 

Refueling  Truck  Flow 

Graphic 

1  pg  (d  12 

Medium 

Unclas 

Single  Aircraft  Summary 

Graphic 

1  pg  (d  500 

Simple 

Unclas 

Supply  M1CAP  Status 

T  abular 

1  pg  (d  48 

Simple 

Unclas 

Task  Capability 

Graphic 

1  pg  (d  12 

Medium 

Secret 

Tasked  Missions 

Graphic 

1  pg  Cd  8 

Simple 

Secret 

Tasked  Munitions 

Graphic 

1  pg  @  23 

Simple 

Secret 

Tasking  Information 

Tabular 

2  pg  (d  120 

Simple 

Secret 

NOTE:  Depending  on  input  parameters,  some  times  will  increase/decrease  depending  on 
the  amount  of  data  retrieved.  For  example,  requesting  Munitions  Capability  for 
60  days  will  double  the  amount  of  data  and  time  over  a  30  day  parameter  input. 

*  NOTE:  Some  classifications  will  have  a  range,  i.e.,  U-T5,  meaning  Unclassified  to  Top 
Secret.  That  range  is  usually  caused  by  the  tasking  classification  being  a 
variable,  e.g.,  some  tasks  are  Unclassified,  some  are  Confidential,  some  are 
Secret,  etc. 


**  This  means  it  is  SECRET  when  it  is  filled  in  with  actual  completion  times. 


32941 


4-9 


ABBREVIATIONS/ACRONYMS 


AML 

Aircraft  Maintenance  Unit 

FUELS CTL  - 

Fuels  Control 

MOC 

Maintenance  Control  or  Job  Control 

MEN  CTL 

Munitions  Control 

OPS 

Wing  &  Squadron  Scheduling/Training,  Squadron  Operations,  Wing  HQ 

woe 

Wing  Operations  Center  (LRC,  PRC,  SRC,  Sr.  Battlestaff,  Mission 
Director,  Frag  Shop) 

TABLE  4-2A 

AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [WING] 


Screen  Title 

Primary 

User(s) 

Supporting 

User(s) 

Aircraft  Availability  (Pie) 

woe 

OPS,  AMU,  MOC 

Aircraft  Availability  (Bar) 

WOC 

OPS,  AMU,  MOC 

Aircraft  Capability 

woe 

OPS,  MOC 

Aircraft  Status 

MOC,  WOC,  AMU 

OPS,  FUELS  CTL, 

MUN  CTL,  SUPPLY 

Aircraft  Tasking 

WOC 

OPS 

Aircrew  Availability 

WOC 

OPS 

Aircrew  Capability 

WOC 

OPS 

Aircrew  Generation 

WOC 

OPS 

Aircrew  Status 

OPS 

WOC 

Airf  ie Id  Status 

WOC 

OPS,  MOC,  AML 

Base  Fuels  Capability 

FUELS  CTL, 

WOC 

Base  Status  (I/O) 

WOC 

FUELS  CTL,  MUN  CTL 
OPS,  SUPPLY,  MOC, 
AMU 

Base  Status  Report  (Rollup) 

WOC 

TABLE  4-2A 


AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [WING]  (Continued) 


Screen  Title 

Primary 

User(s) 

Supporting 

User(s) 

Flying  Schedule  (Ops  Seg  1) 

WOC,  OPS 

AMU 

Flying  Schedule  (Maint  Seg  2) 

MOC 

OPS,  FUELS  CTL,  AMU 
MUN  CTL,  WOC 

Flying  Schedule  Header  File 

MOC,  WOC,  OPS 

Individual  Resource  Capability 

WOC 

OPS 

Integrated  Capability 

WOC 

OPS 

Order  Assignments 

WOC 

OPS 

Munitions  Status 

MUN  CTL 

WOC,  OPS 

Munitions  Availability  Forecast 

WOC 

MUN  CTL,  OPS 

Munitions  Capability 

MUN  CTL,  WOC 

OPS 

Mission  Flow 

MOC,  WOC 

OPS,  AMU,  FUELS 

Mission  Profile  Definition 

WOC 

OPS 

OPLAN/OPORD  Associations 

WOC 

OPS 

Fuels  Status 

FUELS  CTL 

SUPPLY,  WOC 

Process  Status 

WOC 

OPS 

Resupply  Schedule 

WOC 

FUELS  CTL,  MUN  CTL 

Supply  MICAP  Status 

WOC,  MOC 

SUPPLY 

Tasked  Missions 

WOC 

OPS,  MOC 

Tasked  Munitions 

WOC,  MUN  CTL 

OPS,  MOC 

Tasking  Information 

WOC 

OPS,  MUN  CTL,  MOC 

Tasking  Information  File 

AOC 

OPS,  MUN  CTL,  MOC 

Unit  Status  (I/O) 

WOC 

OPS 

A  ing  Flying  Day 

WOC 

OPS 

TABLE  4-2A 


AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [WING]  (Continued) 


Screen  Title 

Supporting 

User(s) 

Wing  Operations  Rates 

woe 

MOC,  OPS 

Wing  Resource  Summary  (O) 

woe 

FUELS  CTL,  MUN  CTL 

Wing  Resource  Summary  (I/O) 

woe 

FUELS  CTL,  MUN  CTL 

Base/Unit  Status  Rollup 

woe 

Resource  Rollup 

WOC 

OPS 

Run  SGM 

woe 

OPS 

Transmit  Base  Status 

WOC 

Transmit  Unit  Status 

WOC 

Transmit  Resource  Status 

WOC 

AGE  Availability 

tMOC 

AMU,  MUN  CTL,  WOC 

AGE  Support  Capability 

MOC,  WOC 

Airfield  Status 

MOC,  WOC,  OPS 

Base  Status  Map 

WOC,  OPS 

Fuels  Capability 

WOC,  FUELS  CTL 

OPS 

Fuels  Capability  (Bar) 

WOC,  FUELS  CTL 

OPS 

Maintenance  Support  Capability 

MOC,  WOC,  AMU 

OPS 

Mass  Load  Generation  Schedule 

MOC,  WOC 

AMU,  OPS,  FUELS 

CTL,  MUN  CTL 

Munition  Flow 

MUN  CTL,  WOC 

AMU,  MOC 

Munitions  A  $c  D  Availability 

MUN  CTL 

MOC,  WOC 

Munitions  Assembly  Capability 

MUN  CTL 

WOC 

Munitions  Capability  (Bar) 

W'OC 

AMU,  MUN  CTL 

Munitions  Distribution  Cap. 

MUN  CTL,  WOC 

MOC 

TABLE  4-2A 


AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [WING]  (Continued) 


Screen  Title 

Primary 

User(s) 

Supporting 

User(s) 

Munitions  Load  Crew  Flow 

AMU 

WOC,  MOC 

Munitions  Load  Crew  Status 

AMU 

VI  OC,  MOC 

Munitions  Loading  Capability 

WOC,  AMU 

MUN  CTL 

Fuels  Status  Map 

FUELS  CTL,  WOC 

Refueling  Capability 

WOC,  FUELS  CTL 

Refueling  Truck  Flow 

FUELS  CTL 

WOC,  MOC 

Single  Aircraft  Summary 

MOC,  AMU 

WOC,  OPS,  FUELS 

CTL,  MUN  CTL 

Task  Capability 

WOC 

OPS,  MOC,  MUN 

CTL,  FUELS  CTL,  AMU 

ABBREVIATIONS/ACRONYMS/AIR  FORCE  CODES 


ALCC 

BS 

COMM 

DOCK 

DO  JN 

DOX 

ESRC 

LGSF 

LOSS 

LGWR 

LGX 

LRC 

PRC 

XPX 


Airlift  Control  Center 
Battle  Staff 
Communications 

Command  and  Control  Reports  Division 

Combat  Employment  Capability  Division 

Operations  Plans  (Contingency /Exercise/Special  Plans) 

Engineering  and  Services  Readiness  Center 

Energy  Management 

Supply  Management 

Munitions  Requirements  Division 

Logistics  Plans 

Logistics  Readiness  Center 

Personnel  Readiness  Center 

Operations  Plans 


TABLE  4-2B 


AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [MAJCOM] 


Screen  Title  (Unimplemented) 

Primary 

User(s) 

Supporting 

User(s) 

Aircraft  Tasking 

BS,  LRC 

DOJN,  DOX,  XPX 

Base  Fuels  Capability 

LRC 

LGSF 

Base  Status  Map 

Reports  Cell 

BS,  LRC 

Base  Status  (I/O) 

Reports  Ceil 

BS,  ESRC,  COMM,  LRC 

Base  Status  (Output) 

ALCC,  BS,  LRC, 

ESRC,  COMM 

Capability  Perspective 

DOCR 

Dollars  to  Readiness  FYxx 

XPX 

DOJN,  LGSF,  LGSS,  LGWR 

Dollars  to  Readiness  FYxx-FYzz 

XPX 

DOJN,  LGSF,  LGSS,  LGWR 

Dollars  to  Readiness-Fuels 

LGSF 

XPX 

TABLE  4-2B 


AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [MAJCOM]  (Continued) 


Screen  Title  (Unimplemented) 

Primary 

User(s) 

Supporting 

User(s) 

Dollars  to  Read.  Associations 

XPX 

LGSF,  LGSS,  LG  A  R 

Fuels  Capability 

LRC 

LGSF 

individual  Resource  Capability 

BS,  LRC 

XPX,  DOX,  DOJN 

Integrated  Capability 

BS,  LRC 

XPX,  DOX,  DOJN 

Munitions  Capability 

LRC 

XPX,  DOJN 

Munitions  Status 

LRC 

BS 

MICAP  Forecast 

LOSS,  LRC 

Mission  Profile  Definition 

DOX,  DOJN 

XPX 

OPLAN/OPORD  Associations 

BS,  XPX,  DOX 

DOJN 

Order  Assignments 

BS,  DOJN 

XPX 

Process  Status 

BS,  LRC,  XPX 

Resource  Reallocation 

LRC 

Resource  Unit  Price 

XPX 

LGSF,  LGSS,  LG  A  R 

Resupply  Schedule 

LRC,  LGX,  BS 

XPX 

Unit  Status  (Output) 

BS,  LRC,  ALCC 

Unit  Status  (I/O) 

Reports  Cell 

BS,  LRC,  ALCC, 
ESRC,  COMM 

A  ing  Flying  Day 

BS,  DOJN,' 

DOX,  XPX 

A  ing  Operations  Rates 

BS,  LRC 

DOX,  LGX 

A  ing  Resource  Summary  (O) 

LRC 

A  ing  Resource  Summary  (I/O) 

LRC 

Base/Unit  Status  Rollup 

DOC  R 

Resource  Rollup 

DOCK 

Run  S-Readiness 

XPX 

TABLE  4-2B 


AF1RMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [MAJCOM]  (Continued) 


Screen  Title  (Unimplemented) 

Supporting 

User(s) 

Run  SGM 

BS,  XPX,  DOX, 

DOJN,  LRC 

Transmit  Base  Status 

,DOCR 

Transmit  Unit  Status 

DOCR 

Transmit  Resource  Status 

DOCR 

Aircraft  Spares  Support  Cap. 

LRC 

LGSS 

Attrition  Statistics 

PRC 

BS 

Attrition  Trends 

PRC 

BS 

Communications  Support  Status 

COMM 

Reports  Cell 

Fuel  Status  Map 

LRC 

ALCC,  BS 

Fuels  FYDP  Procurement  Program 

LGSF 

XPX 

Individual  Resource  Capability 

XPX,LGSF,  LGSS, 

LGWR 

MICAP  Forecast 

LRC 

LGSS 

Mission  Area  Tasking 

DOJN,  XPX 

Mission  <Jc  Aircraft  Tasking 

Detail  Summary 

DOJN,  DOX,  XPX 

BS,  LRC 

Mission  Tasking 

DOX,  XPX,  DOJN 

BS 

Munitions  Procurement  Program 

LRC 

Munitions  Readiness  Sc 

Sustainability 

LRC 

Munitions  Substitution  Sortie 
Capability 

XPX,  DOJN 

LRC 

Munitions  Substitution  Sortie 
Requirement 

XPX,  DOJN 

LRC 

Munitions  Sustainability 

LRC 

BS 

Preferred  Munitions  Objectives 

DOJN,  XPX 

LRC 

ABBREVIATIONS/ACRONYMS/AIR  FORCE  CODES 


CSS 

LEXX 

LEXY 

LEYS 

LEY  W 

LRC 

PRC 

PRPF/R 

XOOOA/XOOOE 

XOOIM 

XOOIR/LERX 

XOXFM 

XOXIC 

XOXIM 

XOXP 

XPX 


Contingency  Support  Staff 

Logistics  Plans  Division 

Logistics  Concepts  Division 

Supply  Policy  and  Energy  Management  Division 

Munitions  and  Missiles  Division 

Logistics  Readiness  Center 

Personnel  Readiness  Center 

Programs  &  Evaluation  Directorate  (Staff,  Programs  6c  Resources) 

Air  Force  Operations  Center/Contingency  Support  6c  Exercise 
Branch 

Readiness  Assessment  Group 

CHECKMATE  Group 

Munitions  Planning  Division 

War  6c  Mobilization  Planning  Division 

Capability  Assessment  Divisions 

Assistant  Director  for  Special  Plans 

Operations  Plans 


TABLE  4-2C 

AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [HQ  USAF] 


Screen  Title  (Unimplemented) 

Primary 

User(s) 

Supporting 

User(s) 

Aircraft  Tasking 

CSS,  XOXIC 

XOXFM,  XOOIR 

Base  Fuels  Capability 

LRC,  LEYS 

CSS 

Base  Status  Map 

CSS 

LRC 

Base  Status  (I/O) 

LRC,  CSS,  XOOIM,  PRC 

XOOOA/XOOOE 

Base  Status  (Output) 

LRC,  CSS,  XOOIM,  PRC 

XOOOA/XOOOE 

Capability  Perspective 

XOOIM 

Supporting 

User(s) 


Screen  Title  (Unimplemented) 

Primary 

User(s) 

Supporting 

User(s) 

Dollars  to  Readiness  Comparisons 

PRP 

LEXX,  LEXY 
LEYS 

Dollars  to  Readiness  -  Resource 
Perspective 

PRP 

LEXX,  LEXY 
LEYS 

Dollars  to  Readiness  Ass. 

PRP 

LEXX,  LEXY 
LEYS 

Fuels  Capability 

LRC,  CSS 

LEYS 

Individual  Resource  Cap. 

LRC,  CSS 

LEYS,  LEXY, 
LEXX,  XOXIC, 
XOOIM 

Integrated  Capability 

LRC,  CSS 

XOOIM,  XOXIC 

Order  Assignments 

CSS 

XOXIC 

Munitions  Status 

LRC 

LEYA 

Munitions  Capability 

LRC 

XOXIM,  CSS, 
XOXFM,  LEYA 

Mission  Profile  Definition 

XOXIC,  CSS 

OPLAN/OPORD  Associations 

LEXX,  LRC,  LEYS,  LEXY, 
XOOIM,  CSS 

Process  Status 

LEXX,  LRC,  LEYS,  LEXY, 
XOOIM,  CSS,  PRP 

Resource  Reallocation 

LRC 

Resource  Unit  Price 

PRP 

LEYS,  LEYA 

Resupply  Schedule 

LEXX,  LEYS,  LEYA,  LRC 

Unit  Status  (Output) 

CSS,  LRC,  XOOIM 

Unit  Status  (I/O) 

CSS,  LRC,  XOOIM 

A  ing  Flying  Day 

CSS 

XOOO  A  /  XOOOE , 
XOXP,  XOXIC, 
XOOIM 

TABLE  4-2C 

AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [HQ  USAF]  (Continued) 


Screen  Title  (Unimplemented) 


Wing  Operations  Rates 


Wing  Resource  Summary  (O) 
Wing  Resource  Summary  (I/O) 
Resource  Rollup 
Run  S-Readiness 


LRC,  XOOIM 


Supporting 

User(s) 


XOOOA/XOOOE, 
XOXP,  LRC, 
XOXIC,  XOOIM 

LEY W,  LEYS 

LEY  W,  LEYS 

XOOOA/XOOOE 


Run  SGM 


Airc-aft  Spares  Support  Cap. 
Attrition  Trends 


XOOIM,  LRC,  LEYS, 
LEXY,  LEXX 

LEXY, LEYS 

PRC,  CSS 


Communications  Support  Status  XOOOA/XOOOE,  CSS 

Fuel  Status  Map  LRC 

Fuels  FYUP  Procurement  Program  LEYS, 


Individual  Resource  Capability 

Mission  Area  Tasking 

Mission  &  Aircraft  Tasking 
Detail  Summary 

Mission  Tasking 

Munitions  Procurement  Program 

Munitions  Readiness  <3r 
Sustainability 


LEYS,  LEY W 
PRPF,  XOXIC 


XOXIC 


XOXIC 


XOXFM, LEY  W 
XOXFM,  XOOIM,  XOXIC 


PRPF 


PRPF 


LEYW 


TABLE  4-2C 


AFIRMS  OUTPUT  REPORT  AND  FUNCTIONAL  AREA  USERS  [HQ  USAF]  (Continued) 


Screen  Title  (Unimplemented) 


Munitions  Substitution  Sortie 
Capability 

Munitions  Substitution  Sortie 
Requirement 

Preferred  .Munitions  Objectives 


Supporting 

User(s) 


LEY  W, PRP 


LEYW, PRP 


LEY  W, PRP 


NOTE:  Some  classifications  will  have  a  range,  i.e.,  U-TS,  meaning  Unclassified  to  Top 
Secret.  That  range  is  usually  caused  by  the  tasking  classification  being  a 
variable,  e.g.,  some  tasks  are  Unclassified,  some  are  Confidential,  some  are 
Secret,  etc. 


4.3.3  Database  Description.  For  additional  AFIRMS  database  requirements  by  subsystem, 
please  reference  the  corresponding  AFIRMS  Database  Specification. 

a.  Database  Identification.  AFIRMS  maintains  databases  as  follows: 

(1)  Real:  This  database  contains  peacetime  and  crisis  tasking  and  other 
day-to-day  operational  data. 

(2)  VI  hat  if:  This  physical  database  is  comprised  of  3  types  of  logical 
databases: 

•  Exercise  -  Contains  data  which  provides  a  simulation  of  an 

actual  crisis  or  exercise. 

•  Ad-hoc  what  if-  Contains  data  which  provides  a  simulation  of  a 

hypothetical  crisis  and/or  situation. 

•  Historical  -  Contains  data  which  provides  a  historical  view  of 

the  real,  exercise,  and/or  ad-hoc  what  if  databases. 

b.  Storage.  The  master  file(s)  containing  the  HQ  USAF,  MAJCOM,  and  W  ING  . 
databases  is  stored  on-line  on  mass-storage  disk  devices,  and  off-line  on 
magnetic  tape  and  formatted  floppy  /microfloppy  disk. 

c.  Database  Query  Capabilities.  The  design  of  the  AFIRMS  database  supports  the 
requirements  for  a  real-time  query  capability  accessing  current  and/or  what-if 
data  for  the  above-named  databases.  Historical  data  resides  primarily  on 
off-line  media  and  is  copied  to  on-line  media  on  an  "as-needed"  basis. 

(1)  Ad  Hoc  Querying.  Users  may  execute  ad  hoc  queries  against  any  on-line 
databases  to  which  they  are  permitted  access.  The  ad  hoc  query  moae  is 
entered  from  the  AFIRMS  executive.  The  user  has  the  ability  to 
interactively  query  the  database  via  an  "English-like"  query  language. 

(2)  What-if  Querying.  A  what-if  capability  exists  to  enable  users  to  input 
hypothetical  quantities  for  resources  in  order  to  better  predict  future 
readiness  capability.  The  data  will  be  entered  into  and  accessed  from  the 
local  database  only  through  the  highly-structured  AFIRMS  environment. 

d.  Database  Backup  and  Restoration.  Backup  of  the  database  to  off-line  media 
occurs  on  a  regular  basis  and  backups  are  maintained  as  follows: 


Backup 

Maintained 

Daily 

5  W  orking  Days 

W  eekly 

5  VI  eeks 

Monthly 

1  2  Months 

Yearly 

5  Years 

Restoration  will  occur  in  the  event  that  data  in  the  database  has  been  lost  or 
damaged.  Whenever  a  transaction  occurs  in  the  local  database,  it  will  be  logged 
to  a  journal  file  for  use  in  the  event  restoration  is  needed.  Restoration  consists 
of  reloading  the  latest  backup  copy  of  the  database  from  off-line  media,  if 
necessary,  and  applying  the  journal  log  file  to  update  the  backup  copy. 


e.  Database  Elements.  AFIRMS  database  elements  are  described  in  the  AFIRMS 
Data  Requirements  Document.  The  Database  Specifications  list  by  name  the 
functional  areas  where  the  data  elements  are  to  be  stored. 
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APPENDIX  A 


Al.  Inter-site  Transaction  Header 


Field  name 


Field  Description 


TRANSJD 

a. 

Transaction  identifier. 

b. 

Each  terminal  shall  have  its  own  ID. 

c. 

The  legal  values  are  1— >65535.  After  65535,  it 
should  rollover  back  to  l. 

TRAN  S_M  SG_L  E  N 

a. 

Transaction  message  length. 

b. 

The  length  shall  be  the  sum  of  the  transaction 
header  plus  data  length. 

c. 

The  legal  values  are  85-->8I92. 

REQ_REP_FLAG 

a. 

Request/Reply  flag. 

b. 

User  interactive  display  software  should 
always  send  requests.  The  host  shall  always 
send  replies  in  response  to  the  request  as  long 
as  the  transaction  was  not  submitted  as  a 
batch  job.  The  host  will  occasionally  send 
unsolicited  requests  to  the  workstations  (i.e., 
update  messages.  It  does  not  expect  a  reply. 

c. 

The  legal  values  are  "Q"  for  request  and  "P" 
for  reply. 

JOBJYPE 

a. 

Interactive/Batch/Network  flag. 

b. 

All  jobs  must  run  interactively  if  they  expect 
a  product  screen  display.  Otherwise,  they  can 
be  run  as  batch.  Note:  batch  jobs  never  send 
back  replies.  Their  status  can  be  monitored 
through  the  batch  monitor  screen. 

c. 

The  legal  values  are  "I"  for  interactive,  "B"  for 
batch,  and  "N"  for  network. 

SRCjNODEJD 

a. 

Source  node  ID. 

b. 

This  is  the  node  ID  of  the  requestor. 

Field  name 


Field  Description 


SRC  TERM  ID 


SRC  USER  NAME 


DST  NODE  ID 


DST  TERM  ID 


DST  USER  NAME 


a.  Source  terminal  ID. 

b.  This  is  the  terminal  ID  of  the  requestor. 

c.  The  legal  values  are  local  site  dependent. 

Note:  the  value  1111  is  reserved  for  host 
generated  transactions  (i.e. ,  unsolicated 
update  msgs) 

a.  Source  username. 

b.  This  is  the  username  of  the  requestor. 

c.  The  legal  values  are  site  dependent.  They 
must  match  the  username  used  for  logging  into 
the  host. 

a.  Destination  node  ID. 

b.  This  field  is  filled  in  by  a  transaction  router. 

It  shall  be  the  same  as  the  SRC_NODE_ID  for 
the  local  requests  that  require  a  reply.  In 
general,  it  shall  always  be  the  node  ID  of 
where  the  transaction  is  destined.  It  shall 
differ  from  the  SRC_NODEJD  only  for 
network  messages. 

a.  Destination  terminal  ID. 

b.  This  field  is  filled  in  by  a  transaction  router. 

It  shall  be  the  same  as  the  SRC_TERMJD  for 
the  requests  that  require  a  reply.  In  general, 
it  shall  always  be  the  terminal  ID  of  where  the 
transaction  is  destined.  It  shall  differ  only  for 
network  messages. 

c.  The  legal  values  are  remote  site  dependent. 

a.  Destination  username. 

b.  This  field  is  filled  in  by  a  transaction  router. 

It  shall  be  the  same  as  the  SRC_USER_NAME 
for  the  requests  that  require  a  reply.  In 
general,  it  shall  always  be  username  of  where 
the  transaction  is  destined. 

c.  The  legal  values  are  site  dependent.  They 
must  match  the  username  used  for  logging  into 
the  host  for  local  transactions.  For  network, 
transactions,  the  username  "*ROLLUP*"  is 
reserved. 


Field  name 


Field  Description 


EXP  DAT  TIM 


MOD_REQJD 


FUNC  REQ  ID 


a.  Transaction  expiration  date/time. 

b.  There  are  four  subfields: 

1.  Expiration  year 

b.  The  legal  values  are  0  — )>  99. 

2.  Expiration  day 

b.  The  legal  values  are  1  --)>  366. 
Note:  366  is  only  valid  for 
leap  years. 

3.  Expiration  hour 

b.  The  legal  values  are  0  ~>23. 

4.  Expiration  min 

b.  The  legal  values  are  0  — )>59. 

a.  Module  request  ID. 

b.  This  field  is  looked  at  only  by  the 
transaction  routing  mechanism  to 
determine  whether  the  transaction  is 
destined  for  the  database  server  or 
somewhere  else. 

c.  The  legal  values  are  1  ~>  2.  Their 
meanings  are  as  follows: 

1  =  forward  transaction  to  the 

database  routing 

2  =  AFIRMS  service  request 

a.  Function  request  ID. 

b.  This  field  is  looked  at  by  the 
transaction  routing  mechanism  only 
when  MOD_REQ_ID  =  2.  It  signifies 
what  AFIRMS  service  to  perform. 
Currently,  the  only  service  is  to  log  off 
the  user. 

c.  The  legal  values  are  1  --■>  10.  Their 
meanings  (when  MOD _REQJD=1)  are  as 
follows: 

1  =  organize  records  (send  transaction 

it  2) 

2  =  update  record 

3  =  insert  record 

4  =  delete  record 

5  =  logoff  Database 

6  =  Edit  info  (send  transaction  //l) 

7  =  insert  continuation  record 
S  =  delete  continuation  record 
^  =  log  invalid  batch  job 

10  =  transmit  rollup  status 


A- 3 


3  3591 


Field  name 


MSG  PRIG 


MSG  ST  AT 


MSG  SEG  CUR 


MSG  SEG  TOT 


Field  Description 


a.  Message  priority. 

b.  This  field  is  used  by  the  process 
controller  to  put  each  transaction  it 
receives  into  the  appropriate  priority 
mailbox  (i.e.,  queue). 

(1)  Transaction  router  uses  it  as  a 
consistency  check  to  make  sure  the 
transaction  is  sent  to  the  right 
mailbox,  and 

(2)  to  set  the  priority  of  the  Database 
server  that  will  be  processing  that 
transaction,  and 

(3)  Database  server  uses  it  to 
determine  which  priority  mailbox 
to  forward  replies  to. 

c.  The  legal  values  are  1  for  low  priority, 

5  for  medium  priority,  and  9  for  high 
priority. 

a.  Message  status. 

b.  This  field  is  used  for  returning  the 
status  of  a  user's  request. 

c.  The  legal  values  are  any  32-bit 
number.  Note:  MSG_STAT  must  be 
initially  set  to  0  in  the  original  request. 

a.  Message  number  current. 

b.  This  field  is  the  current  message 
segment  number.  It  is  always  1  unless 
there  is  a  multi-part  transaction  (i.e., 
one  that  must  split  because  it  is  too 
large  for  a  single  buffer). 

c.  The  legal  values  are  1  —  235. 

a.  Message  number  total. 

b.  The  legal  values  are  1  --  255. 


D  T  A 


A. 2  Inter-site  Transaction  Specifications 
NOTE: 

DTG  =  Date  Time  Group 

ETIC  =  Estimated  Time  In  Commission 

A. 2.1  Interface  Specification  -  Base  Status  ROLLUP  Date:  31-May-19S5 
The  buffer  layout  for  the  Base  Status  ROLLUP  is  as  follows: 


Screen 

ID 


It  of 

Parameters 


//  of  base 
reports 
included 


Repeats  It  of  base  reports  included  times* 


length  of 
base  ID 

base 

ID 

status 

status 

length 

II 1 

status 

status 

length 

Ilk 

Itk 

status 

status 

length 

It  7 

It  7 

base  status 
ROLLUP  DTG 


status 

length 


status 
length 
It  5 


status 
length 
//  8 


ETIC 

length 

ETIC 

status 

It  2 

status 

length 

status 

U7> 

status 

It  5 

status 

length 

It  6 

status 
//  6 

status 

//  8 

status 

length 

It  9 

status 
//  9 

Field  name 


Field  Length 


Screen  ID  2 

it  of  Parameters  2 

it  of  base  reports  3 

length  of  base  ID  2 

base  ID  ? 

base  status  ROLLUP  DTG  14 

ETIC  length  2 

ETIC  ? 

status  length  //I  2 

status  it  1  (overall)  ? 

status  length  it  2  2 

status  it 2  (communications)  ? 

status  length  it 3  2 

status  #3  (fuel)  ? 

status  length  itk  2 

status  //4  (maint.  support)  ? 

status  length  //5  2 

status  //5  (munitions)  ? 

status  length  //6  2 

status  it 6  (NBC)  ? 

status  length  iH  2 

status  it7  (runway)  ? 

status  length  //8  2 

status  //8  (supply)  ? 

status  length  // 9  2 

status  //9  (transportation)  ? 


NOTE:  (*)  each  field  whose  length  is  represents  a  variable  length  field.  Only  these 
fields  shall  be  preceded  by  a  2-byte  length  descripter  field. 
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A.2.2  Interface  Specification  Unit  ROLLUP  Date:  31-May-l  9S5 
The  buffer  layout  for  Unit  ROLLUP  is  as  follows: 


Screen 

it  of 

it  of  wings 

ID 

Parameters 

reported 

Repeated  it  of  wings  reported  times* 


it  of  squadrons 

length  of 

wing 

ROLLUP 

for  this  wing 

wing  ID 

ID 

DTG 

Repeated  it  of  squadrons  for  this  wing  times* 


length  of 

squadron 

length 

MDS 

it  of 

it  of 

squadron 

ID 

of  MDS 

PAA 

locations 

I —  Re 


Field  name  Field  Length 


Screen  ID  2 

it  of  Parameters  2 

it  of  wings  reported  3 

it  of  squadrons  for  this  wing  2 

length  of  wing  ID  2 

wing  ID  ? 

ROLLUP DTG  J4 

length  of  squadron  2 

squadron  ID  ? 

length  of  MDS  2 

MDS  ? 

it  of  PAA  3 

it  of  locations  2 

base  short  name  4 

number  possessed  3 

number  MC  ACFT  3 

number  MR  ACRW  3 


peated  it  of  locations  times* 


base  short 

number 

number 

number 

name 

possessed 

MC  ACFT 

MR  ACRW 

NOTE:  (*)  each  field  whose  length  is  represents  a  variable  length  field.  Only  these 
fields  shall  be  preceded  by  a  2-byte  length  descripter  field. 


A. 2.3  Interface  Specification  -  Resource  ROLLUP  Date:  31-Ma>-1985 

The  buffer  layout  for  Resource  ROLLLP  is  as  follows: 


Screen 

it  of 

it  of  wings 

ID 

Parameters 

reported 

Repeated  it  of  wings  reported  times* 


length  of 

VI  ing 

Resource 

it  of 

it  of 

it  of 

it  of 

VI  ing  ID 

ID 

ROLLLP 

PAA 

MC 

MR 

locations 

DTG 

ACFT 

ACFT 

ACRW 

per  \V ing 

Repeats  it  of  locations  per  Vt  ing  times* 


length  of 

it  of 

location 

location 

records  per 

location 

Repeats  it  of  records  per  locations  times* 


length  of 

resource 

length  of 

resource 

type 

amount 

amount 

type 

Field  name 
Screen  ID 

Number  of  parameters 
Number  of  wings  reported 
Length  of  wing  ID 
'A  ing  ID 

Resource  ROLLLP  DTG 
Number  PA  A  ACFT 
Number  \1C  ACFT 
Number  MR  ACR\* 

Number  of  locations  per  wing 
Length  of  location 
Location 

Number  of  records  per  location 
Length  of  resource  type 
Resource  type 
Length  of  amount 
Amount 


Field  Length 


NOTE:  (*)  each  field  whose  length  is  represents  a  variable  length  field.  Only  these 
fields  shall  be  preceded  by  a  2-byte  length  descripter  field. 
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